Re: performing actions in subcomponent
Re: performing actions in subcomponent
- Subject: Re: performing actions in subcomponent
- From: Chuck Hill <email@hidden>
- Date: Mon, 28 May 2007 22:34:34 -0700
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...
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?
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().
since it can refer to the inner class. But the code in that inner
class did mix that type of display logic and also some model-type
logic related to editing time entries on specific days. So, I agree
that moving that out makes sense.
I would go further than "logic related to editing time entries on
specific days". If you have a DayComponent (the inner class), it
should know which Day it is. So the isSelected() method on it is
implemented as
public void setIsSelected(boolean isSelected) {
isSelected ? day().calendar().selectDay(day()) : day().calendar
().deSelectDay(day());
}
public boolean isSelected() {
return day().calendar().isSelected(day());
}
The UI (component) is just a thin wrapper about the Calendar logic
that maintains a list of selected days. The wrapper methods are UI
logic. Maintaining a list of selected days is model logic.
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.
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
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
_______________________________________________
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