[
http://issues.apache.org/jira/browse/TOMAHAWK-175?page=comments#action_12369030
]
Jurgen Lust commented on TOMAHAWK-175:
--------------------------------------
I think that returning the start time and end time is not the responsibility of
the schedule component anymore. When you can retrieve the selected point in
time, it's up to the handler of the specific application to determine what
start and end time you want to use. Some applications will just want to take
the half hour or hour surrounding the selected time, others will want to use
all available time, etc.
So I think the lastClickedDateAndTime property should be sufficient.
The reason why I put the lastClickedDateAndTime only in the component, is
because I do not feel it belongs in the model. That really is information
specifically about the view (a mouse click). Isn't it a bigger sin to put
view-specific stuff in the model, than putting a component binding in the
controller?
Moreover, the lastClickedDateAndTime should have a value during only 1 request,
right after the schedule was actually clicked. When the form is submitted by
another means, for example a submit button, or by selecting an entry, this
property must be null, so that you can check in the controller if the schedule
was actually clicked. When you put this information in the model, and the model
is session scope, then this value stays there for as long as the session lasts,
which would lead to strange behaviour I think.
Let's take a Swing component like the JList as an example: you don't add
MouseListeners to the ListModel, you add them to the JList component itself. I
think the same should be true in this case.
Come to think of it, why not define a ScheduleMouseListener interface with the
following method?
public void scheduleClicked(ScheduleMouseEvent event);
The ScheduleMouseEvent would then have properties such as: clickCount,
clickedDateAndTime, popupTrigger, clickedEntry, ...
Then you wouldn't need a binding in your handler class. Best of both worlds :)
> schedule component: select available time slots to create new entries
> ---------------------------------------------------------------------
>
> Key: TOMAHAWK-175
> URL: http://issues.apache.org/jira/browse/TOMAHAWK-175
> Project: MyFaces Tomahawk
> Type: Improvement
> Versions: 1.1.2-SNAPSHOT
> Reporter: Stefan Betermieux
> Assignee: Jurgen Lust
> Attachments: schedule-clickable.patch
>
> Hi,
> our group is using the schedule component in a time management application
> and user evaluation showed that the entry of new appointments is cumbersome.
> We used to have an "add entry" button next to the week view, where the user
> had to select the day and time for start and end of the appointment, just
> like the EntryHandler in the examples do. We opted for a simple solution
> which adds a lot of usability:
> - if there are no appointments for a single day, put a transparent entry in
> the schedule, which behaves like a normal appointment (selectable) and which
> spans the whole day.
> - if there is for example one appointment arround noon, replace the first
> transparent entry by two transparent entries around the visible appointment.
> - repeat as needed...
> At the end, there is no unselectable space left for a single day, it is
> either a block representing an appointment or an invisble but selectable
> block representing available time.
> If a transparent block is selected, put the start and end time in the model.
> Take a look at our modified sandbox example web app, which implements the
> described behaviour:
> http://sirius.fernuni-hagen.de/myfaces-example-sandbox/schedule/example2.jsf
> (because of TOMAHAWK-173, the creation of new entries has to be triggered by
> a commandButton on the left side after selecting the time slot)
> The modifications are mostly renderer based, the model had just to be changed
> to support the start and end dates of the selected available time slot.
> There are no modifications of existing code bases using the schedule
> component if AbstractScheduleModel has been extended. If ScheduleModel is
> implemented, the new methods of the interface to get and set the start and
> end time should be added.
> I am not yet providing a patch because some questions have to be discussed:
> - would this be a desirable behaviour for general schedule users, or is it
> just our use case?
> - should this behaviour be optional? (At the moment, it respects the readonly
> flag, but there may be situations where appointments should be selectable,
> but the available time slots should not be)
--
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
