Re: performing actions in subcomponent
Re: performing actions in subcomponent
- Subject: Re: performing actions in subcomponent
- From: Chuck Hill <email@hidden>
- Date: Tue, 29 May 2007 16:20:02 -0700
Hi Tim,
On May 29, 2007, at 12:51 AM, Timmy wrote:
I've attached a pic that demonstrates what I'm doing. My prior
working version has many more controls but this should give an
idea. This is only the representation for an exempt employee.
On May 28, 2007, at 10:34 PM, Chuck Hill wrote:
Hi Tim,
On May 28, 2007, at 9:53 PM, Timmy wrote:
I thought it might be useful for me to give some more details
about the app and model to make sure that the concensus is that
I'm way off the mark. :-) The Calendar and Day representations in
the respective components really are for display only.
But why? You seem to have Calendar and Day concepts, why not make
them objects? They don't have to be EOs, just plain old Java
objects will do. It still seems (to me anyway) that you have
concepts here that are not directly tied to their display. A Day
can exist without an HMTL page...
Yeah, I get that and I think you're definitely right that a Day
object is valuable in a number of ways.
So, the calendar itself is just an abstract display component
that represents a PayPeriod EO and allows users to interact with
a specific Timesheet EO (for that PayPeriod).
Each PayPeriod has one or more TimeSheets associated with it? Is
each TimeSheet a day? A shift? A week? If a TimeSheet is a
week, how are the individual days / shifts represented in your EO
Model?
A Timesheet EO is really just a correlation of PayPeriod and Job
with attributes for status and access lock (as it moves through
approvals). So, a user's display calendar is drawn based on their
Job and PayPeriod. The following would represent this aspect of my
model:
Employee ->> Job ->> Timesheets ->> TimeEntry
PayPeriod ->> Timesheets ->> TimeEntry
Timesheet <-> Job
Timesheet <-> PayPeriod
One person can have multiple TimeEntries for one day, right?
So, any changes a user makes on the CalendarComponent are recorded
as TimeEntry records associated with a Timesheet. PayPeriod and Job
are both mandatory to a Timesheet. It seems to me that this
Calendar object we've been talking about could really collapse
together with Timesheet. They occupy very similar logical places
and both require the same mandatory items to be properly represented.
Or perhaps Calendar wraps Timesheet to "translate" it into a form
more suitable for driving the UI.
My statement that "logic is driven by an inner class" may have
been a bit misleading in the sense that it was done that way
mostly for display purposes - namely that the CalendarComponent
would have knowledge of which day(s) "isSelected" via WOCheckbox
The Calendar should have knowledge of which days were selected,
yes. But the CalendarComponent should only be responsible for
showing the days that the Calendar says are selected, calendar
().selectedDays().
OK, so I think this is where I may have been holding myself up
based on my own misunderstanding. I'd previously avoided putting
any display logic in my frameworks based on prior advice.
That was good advice. Don't do that. However - it can be hard to
see what and what is not display logic. See next.
However, I can see from your advice that if I'm creating custom
objects that are not EO's, it makes perfect sense to mix in some
display logic like isSelected() or selectedDays().
Those don't seem like display logic to me. They seem like model (as
in MVC not EOModel) logic. Which items are selected is not display
logic. How an items _appears_ when it is selected is display logic.
You could make many different appearing UIs (change the font, change
the background color, show an image, a checkbox) that indicate
selection but the fact of being selected or not remains the same.
That is why the data (am I selected?) belongs outside the UI component.
And I should probably add this to the app as opposed to the model
framework?
That depends on what else you have in your framework. To me, it
sounds like something I would put in the framework.
I think that is more what has been holding me up than anything
else. It probably sounds silly but that is why I was wondering how
I was going to get a reference to some display related methods when
it was no longer being driven by an easily accessible inner class.
Old frames of reference die hard.
:-)
But my model doesn't really have a representation of "Day" as an
entity because a timesheet does not need to know about all the
days in the period - it only needs to know about the the time
reported and what day (NSTimestamp) that time correlates to. So,
as a result, I only draw all of the days of a calendar to
facilitate reporting time.
It may not belong in the model, but it does seem to belong in your
app. Also, I question your statement, "a timesheet does not need
to know about all the days in the period - it only needs to know
about the the time reported and what day (NSTimestamp) that time
correlates to". While it does not need to know all the days, how
does it track the (multiple, I assume) days and times reported for
them? It sounds like your model should be PayPeriod ->> TimeSheet
->> Shift (or Day or something). It seems like there is a
correlation between shifts and calendar days that would be useful
to model, whether in a POJO or EO.
A TimeEntry EO has attributes for the type of time reported (sick,
vacation, etc.), time in minutes, and the date for the item. Each
time entry record relates to a Timesheet. I can ask a Timesheet for
all of its TimeEntry items.
There definitely may be other ways for me to model for sure. Part
of the problem here at UCLA is that there are systems, data
structures, and culture in place that you just need to work with
and not against. Here, there are two types of pay periods (MO & BW)
so your idea of Shift is already covered by that.
Perhaps then you need a non-EO Day object where Day ->> TimeEntry?
Calendar and Day would wrap Timesheet, TimeEntry etc to provide a
model closer to the user's view of a monthly calendar and thus make
the UI easier to implement. You could have
public NSArray days();
on TimeSheet that created a list of Day objects as assigned the
TimeEntries in the sheet to the appropriate Day objects.
I can see where having a "Day" EO would help with some of the
problems I am experiencing. But one of the more basic problems I
still think I would have is that the parent calendar still needs
to know which DayComponent objects are selected via WOCheckbox
and with no "inner" way to reference that, I get stuck.
Which is why the Calendar should be concerned with things like
that and the CalendarComponent should be concerned with looking
pretty in HTML. The same for Day and DayComponent.
Chuck
Thanks much.
My pleasure.
Chuck
Tim
On May 25, 2007, at 9:32 AM, Chuck Hill wrote:
You are going about it the wrong way. This is making you want
to do things that you can not and should not want to do.
"Logic is driven by an inner class CalendarComponent.DayCell"
"can't figure out how to execute the working actions in
CalendarComponent from this perspective"
It seems you are following the Muddled-View-Controller
pattern. :-) The Model-View-Controller pattern will make this
much more workable. You need to build a data model for the
days, months, calendar that is _separate_ from the UI. The
action methods in the pages just call into this:
public WOComponent markAsHoliday() {
selectedDay().markAsHoliday();
return context().page();
}
The page / components will all have a reference to this model.
Performing actions (calling methods on your calendar data model)
is then as easy in DayComponent as it is in CalendarPage. You
will find that this makes things much simpler in your classes.
A rule to keep in mind: If you are writing code in a WOComponent
sub-class (and an inner class is the same thing) that is not
_directly_ concerned with the HTML being output then you are
doing something wrong. That code needs to be moved someplace else.
Chuck
On May 24, 2007, at 11:07 PM, Timmy wrote:
WO List:
My project has a large monolithic WOComponent that draws a
calendar (WOTable) with the ability to select checkboxes in
each day to effect a change on that day. This has functioned
very well for some time now. But I've decided to try and split
this component into multiple subcomponents in order to address
some feature requests that would make it useful for a plain
calendar to be presented alone (without widgets, buttons, etc.)
- for printing for instance.
So, I've created the following 3 subcomponents:
1. DayComponent - presentation of a day with appropriate
widgets and checkbox for selection. Logic is driven by an inner
class CalendarComponent.DayCell
2. CalendarComponent - full month display of DayComponents
built using a WOTable iterated over an array of
DayComponent.DayCell objects
3. CalendarPage - user functional page with widgets to interact
with calendar, select individual days on the calendar, and
execute actions.
In testing, if I display CalendarComponent and have all my
actions take place there, they work just as they did in the
monolithic approach. So, one level of subcomponent
(DayComponent) appears to work well nested inside
CalendarComponent.
However, I don't want all the buttons, etc. on this component -
just an abstraction of the plain calendar. Instead, I want
users to be directed to the CalendarPage (with
CalendarComponent embedded) where all of the buttons etc are
presented to take actions on the calendar. The problem is that
I can't figure out how to execute the working actions in
CalendarComponent from this perspective. In one approach to
fixing the problem I moved some of my action methods to the top-
level component and made sure there was a binding for the
collection of DayCells to there (which seems redundant to me).
But under that scenario, those actions continually think that I
haven't selected any day checkboxes.
Mostly, I recognize that my project's best interests are not
served well by my knowledge level so I need that "a-ha" moment
to stretch. :-)
It seems to me that ideally I want to be able to do the
opposite of performParentAction() which I have used elsewhere
in the project. It seems to me that I want to be able to
execute actions in CalendarComponent from the parent
CalendarPage but it isn't apparent to me that any solution I've
found in my searches fits this design.
Am I approaching this the wrong way or is there a simple way
for me to address actions in a child component using an
enclosing form and widgets that are both resident on the parent?
regards,
Tim
Programmer/Analyst
UCLA GSE&IS
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve
specific problems.
http://www.global-village.net/products/practical_webobjects
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve
specific problems.
http://www.global-village.net/products/practical_webobjects
<Picture 3.png>
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden