Re: performing actions in subcomponent
Re: performing actions in subcomponent
- Subject: Re: performing actions in subcomponent
- From: Timmy <email@hidden>
- Date: Mon, 28 May 2007 21:53:29 -0700
Chuck, et al:
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. 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). 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 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.
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.
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.
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
_______________________________________________
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