Re: performing actions in subcomponent
Re: performing actions in subcomponent
- Subject: Re: performing actions in subcomponent
- From: Timmy <email@hidden>
- Date: Tue, 29 May 2007 00:51:39 -0700
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
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.
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. 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(). And I should probably add this to the
app as opposed to the model 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.
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.
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 (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
Attachment:
Picture 3.png
Description: application/applefile
_______________________________________________
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