JBossDeveloper

Hi Nick, as you have seen in demo you have written, widget can accept callback functions on event selection, day selection, event moving or resizing. Same as navigating between dates. We just have to provide functions that will do ajax in the richfaces style.

Target object seems to be more appropriate. Will this introduce any problems?

I think not at all, since widget will send eventId as request param and UISchedule can fetch target object from datamodel during broadcast.

Should we generate standalone listener tags? I don't get the idea why it is not an attribute in tree.

it will require explicit addition of a4j:support. I prefer the second variant.

How do we send additional data, like dayDelta or eventId when we attach a4j:support?

I guess a4j:jsFunction would have to be used and wrapped by user's function that would be a callback for widget. This will decrease reuse, for the same functionality will have to be repeated for each schedule tag on the page and in each project.

Ok, so javascript updates inputs on client side on item resizing, moving and selecting.

Now, dev adds <a4j:support action="#{bean.itemSelected}"/> but how should that method know which item was selected? It is the component that should do the decoding. Should component have attributes like "selectedItem", "dayDelta", "minuteDelta" that could be bound to "bean" ?

I think we should just have those modes "ajax", "client", "server". If you are working in "ajax" mode then all listeners are fired during ajax request. If you are working in "server" mode then every clicking, resizing, moving will cause form submit (this mode would probably be just for displaying, and very rarely used). If you work in "client" mode then attaching listeners would be cause exception. This way devs will have ease of use (just define swithType instead of attaching a4j:support).

Edited one day later:

There is also other attitude. Resizing, editing and selecting by default works only on client side. If dev wants backing beans to be updated on server side, he should attach a4j:support. I consider it a poor solution.

Other question is how do jboss-el works? i.e.: #{bean.itemSelected(item)}. Cause devs would like it most to attach <a4j:support action="#{bean.itemSelected(item)}". Should UISchedule set selected index on data model during broadcast? If so then should it be done with setRowIndex or setRowKey? Anyway those methods are used by JSF to iterate over datamodel. What is the guarantee that selection made during broadcast (apply request values phase i guess) will remain the same until invokeApplication or other time when a4j:support will execute action?

I'm having problems component caching data. The "date" attribute is bound to managed bean property via EL. I submit form that updates that property, but cached "_date" attribute is cached on UISchedule. When shall I clear it, or should it be done automatically?

Time for demo: http://bernard.labno.pl/schedule-sample

Nick, problem from last post was due to my implementation. Sorry for false alarm.

Questions:

1. How about merging events data in broadcast method sent back on ScheduleLoadEvent (fired on displayed date range change) with data requested by user "<rich:schedule data="tralalala"/>
2. Please look at UISchedule src (getCalendarData method) and guide me with data model visitor. I don't know what process method should do.
3. There are two options for navigation between dates. Which do we choose :
   1. fire event and force developer to provide event listener that will change data model
   2. check if data model is ExtendedDataModel and send DateRange (new, custom implementation of Range) - current implementation
4. If we go with option 3.2 then should we still fire DateRangeChangedEvent?
5. Should getItemMovedListener method from UISchedule return MethodBinding or MethodExpression?
6. When should we fire listeners from getFacesListeners()? After reading JSF2 specs I guess that it should be before firing method expression bound to xxxListener (i.e. itemMovedListener) attribute. In which phase should such events be fired?
7. Currently all event listeners are declared as properties of component (itemMovedListener, itemSelectedListener) which allows only one listener per each event to be registered. Should we allow more listeners to be registered? If so then how, via some custom tag or is there other solution?
8. Sending xxEvent object to listener methods binds them tightly to RichFaces. I'm wondering if we couldn't make it different so that backing beans wouldn't have to rely on RichFaces api.
9. I have already created 5 events for item moved, item resized, item selected, schedule load, view changed. Isn't this too much? I think not.
10. Which name do you prefer ScheduleLoadEvent or DateRangeChangedEvent?
11. How should parsing exceptions in decode method be handled? Packed into RuntimeException and rethrown, logged as warnings?
12. What's the difference between using scopeChain variables and object properties (i.e this.id) - check richfaces.fullcalendar.js

Last thing, I've run into frustrating problem in Webkit (safari,chrome) based browsers. If content type is set to application/xhtml+xml then some DOM modifications just won't work (i.e. div.innerHTML=" " will work from page, but not if it is located in external js file). This artilce http://j4fry.blogspot.com/2009/06/jsf-20-and-dojo-create.html suggest to apply listener that would change the content type, but we cannot force people to do that to get our component working. Here is the link to issue in webkit bugtracker, it doesn't seem they are going to fix it. What shall we do? This is very, very old bug of webkit.

TODO: http://docs.google.com/View?id=dfhnwkfw_9hf76sff9

Hi Nick,

Thanks for thorough answer. I've fixed fullcalendar.js as you suggested and the widget rocks under Chrome. I've also posted an issue at fullcalendar bugtracker. I've added listener tags for each event and split ScheduleListener into 6 different listeners (also added new event).

Widget has an option to revert item moving or resizing. I've implemented it in such a way that listener bound via EL can return boolean which is used to decide if revert is required (in other words if modification is allowed by server side code). As for now, listeners attached via tags or UISchedule.addXXXListener cannot veto the operation. Do you think, they should? If so then how? I think that we cannot use returned value because it would be eaten by xxxEvent.processListener. We could allow throwing java.beans.PropertyVetoException, but then I guess we cannot pass such event to super.broadcast which I've put now at the end of broadcast() method. I guess it should be done like this:

if (event instanceof ScheduleDateRangeChangedEvent) {
  ...
  super.broadcast(event);
} else if (event instanceof ScheduleItemMoveEvent) {
  FacesContext facesContext = getFacesContext();
  AjaxContext ajaxContext = AjaxContext.getCurrentInstance(facesContext);
  MethodBinding expression = getItemMoveListener();
  boolean allow = true;
  if (expression != null) {
    Object result = expression.invoke(facesContext, new Object[]{event});
    allow = ((Boolean) result);
  }
  try {
    super.broadcast(event);
  } catch(PropertyVetoException e) {
     allow=false;
  }
  ajaxContext.setResponseData(allow);
} else if (event instanceof ScheduleItemResizeEvent) {
  ...
  super.broadcast(event);
} ... else {
     super.broadcast(event);
}

Yet there is a question: should all listeners be notified even if event was vetoed by anyone? Also what should be fired first, EL bound listener or the ones attached by API or tag?

Shall we enumerate firstDayOfWeek as in Calendar (sunday=1,monday=2,etc.) or like in widget(sunday=0,monday=1,etc.)?

As to naming, I've made a distinction: events that can be vetoed are named in present form and ones that cannot be undone use past form of verb, i.e.: DateRangeChangedEvent (range was changed and nothing can revert it), ScheduleItemMoveEvent (there is an attempt to move item, but listeners may veto it). What do you think about this convention? If you don't like it we can change all names to use present form of verb.

Widget caches initialEvents. Perhaps it should not because state on server side may change. Note that in ajax mode when you navigate one month back, the request is made, but when you navigate back to initial month, then no request is made and widget uses old values. Well, actually it is our facade that does that:).

Shouldn't we check if there is at most one renderable UIScheduleItem child?

How about reRender,ajaxSingle and others? How to put such info into generated js function?

What about Text/Time Customization ? I think, we should provide appropriate entries in messages.properties, but who to pass it to widget? There are two options:

1. put everything in options (bad because request size grows)
2. generate script resource (I don't know how, please point me to some example) and attach it with <script src="..."/>; such script would have to contain something like this : jQuery.extend(RichFaces.Schedule.messages,{'pl':{monthNames:...}} if locale is set to polish

As to option 2, i'm trying to extend InternetResourceBase and override getResourceAsStream, but I can't figure out how to access appropriate resource bundle.

edited later:

As to text/time customization point 2:

Ok, so I've found out that overriding needFacesRequest() method to return true turns FacesContext on. But next question arises. In JSF 1.1 there can be only one message bundle (which is easy to access via FacesContext.getCurrentInstance().getApplication().getMessageBundle()). If user uses only one file with messages that's fine, but since JSF 1.2 users can use multiple resource bundles. Should our component be aware of this? If so then I do not know how to get names of all defined resource bundles. Also Seam based apps use their custom mechanism for multiple messages files. Users used to such facility will have hard times figuring out how to configure their app so that schedule uses their custom messages. What is your proposition?

Problem with component is that items are not rendered as standalone html, but are created by main component via JavaScript, so we cannot use it as standard UIData component that only renders children. (well, we could, but we would have to reRender entire widget on every request - item resize, move, etc. and that would decrease performance and make widget blink).

Probably we could force widget to refetch items without rendering after each event, but that would cause 2 ajax requests per event (one to raise event and one to refetch items) and drastically increase traffic.

edited later:

I've implemented full internationalization support via standard JSF mechanism.

I've also adopted new version of fullcalendar with option to quickly create items via click-drag.

Check out demo.

Source code is available at svn://bernard.labno.pl/richfaces