[ http://issues.apache.org/jira/browse/TOMAHAWK-438?page=comments#action_12413677 ]
Jurgen Lust commented on TOMAHAWK-438: -------------------------------------- I applied your patch and tried running the examples, quickly discovering the problem that caused me not to add mode and selectedDate attribute to the component: When you try example 3, the customizable schedule, you will understand what I mean. The ScheduleModel needs to know the selected date and the mode of the schedule, to determine which timespan to load. For example, if the selected date is Tuesday, May 31st 2006 and the mode is WORKWEEK, the timespan that should be loaded by the model is Monday, May 29th 2006 00:00:00 until Saturday, June 3rd, 2006, 00:00:00. You could argue that determining the span should not be done by the model, but rather by the component itself, and move these 2 properties to the component, but then you would need a binding to the component if you wanted to do something with the selected date in one of your backing beans, which is not very desirable. So, the thing you are trying to fix because you feel it stands in the way of a clean MVC implementation, was put in there with exactly that purpose in mind... As for changes [3] and [4], I will add those separately. > Schedule Component TLD changes > ------------------------------ > > Key: TOMAHAWK-438 > URL: http://issues.apache.org/jira/browse/TOMAHAWK-438 > Project: MyFaces Tomahawk > Type: Improvement > Components: Schedule > Versions: 1.1.3-SNAPSHOT > Environment: All > Reporter: Julian Ray > Assignee: Jurgen Lust > Fix For: 1.1.3-SNAPSHOT > Attachments: schedule-example-patch.txt, schedule-example-patch.txt, > schedule-example-patch1.txt, schedule-patch.txt > > I would like to propose some changes to the TLD for the sandbox Schedule > component as follows: > [1] Add a requried "mode" property (String) with values "day" "workweek" > "week" "month" > [2] Add an optional "selectedDate" property (Date) value binding which sets > the current date > [3] Change the definition of the "entryRenderer" property to be an optional > value binding. > The reasons for [1] and [2] are that it allows better seperation of the model > from the view (and backing bean if used) especially for key view properties. > These properties must currently be set on the model which propagates their > effect to the view. > [3] is motivated by a need to subclass ScheduleEntryRenderer and allow > additional properties to be used during the rendering. Currently, the > property takes a class name and creates an instance using a default > constructor. > I can submit a patch implementing these changes. > Julian -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
