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 20:34:10 -0700
Hi Tim,
On May 29, 2007, at 4:57 PM, Timmy wrote:
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.
... exactly the approach I am using now.
Sounds like you are on the right track.
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.
I really like this explanation and it is very valuable. Hopefully
anyone who has been stuck where I was gets this far in our
conversation.
Success! :-)
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.
This is exactly the approach I'm using now and the original "inner
class" approach was somewhat doing the same thing but it is clear
that moving much of the logic was a much better approach. I am
drawing the calendar (again) and things look good. The linchpin was
really making sure that day() retained its reference to calendar
which was addressed by a "smarter" constructor :-) and your
isSelected approach. I really appreciate you taking the time to
illustrate these ideas for me and I hope this discussion proves
useful to other developers down the road. If I ever make it to WWDC
you won't pay for drinks. Wait, how much do you drink?
Is there an emoticon for evil grin? :-P
Chuck
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
On a happier path,
Tim
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 (Webobjects-
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
--
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