Schedule

[blabno]

Hello!

It's time to start schedule development. I suggest using jquery.fullcalendar.js. I've tried it and it is really well written.

It allows eager and lazy loading (pagination). To do lazy loading of calendar events JS component must be provided with URL from where it will receive JSON formatted event list (it passes start and end date). Primefaces just call the same URL, as the page on which the component is used, but only that component is being re-rendered. The component seeks for "startDate" param. If found, then in stead of rendering HTML and JS it renders JSON output.

1.Tell me how we should do it. I've tried A4J.Ajax.Submit, but it substitutes the entire markup, which I do not want (The calendar is removed from the page and the JSON response is plugged in). Shall I use jQuery.ajax?

2.What parameters must be passed in such query so that only one component would get rendered (to compact response)? Short description of params for ajax request would be appreciated.

3.How are the event listeners fired and attached?

4.During event editing it will be resized and dragged. Appropriate events should be fired, but I guess only in ajax mode. So if mode is set to non-ajax should events be submitted? If so then when?

Following has been added after several months:

Demo, download and subversion address are here.

Make sure to use default script and style loading strategies.

Message was edited by: Bernard Labno

[ilya_shaikovsky]

Sorry still not looked into impl questions. Just general comments for other members

• I highly vote for splitting the current calendar into two components - calendar input and scheduler.
  • Scheduler should be encoded at server side instead of building at client as for 3.3.x - that will allow highly customize the content cells (e.g. current design could not support iterations inside.)
• From customization points of view - initially i think you should review current calendar customization points(at least at base ones) Need to doublecheck if the script plugin you proposing really fit the needs. If it would not allow some customization - it should be rewritten/extended. But component functionality should not be limited just because we want to use some existent client side widget.
  • later it highly possible that we will want to extend it more after review.

[nbelaevski]

Hi Bernard,

I've created small prototype application that shows how this full calendar can be integrated with RF built-in AJAX. It's here: http://anonsvn.jboss.org/repos/richfaces/branches/community/3.3.X/sandbox/samples/full-calendar , please take a look.

Comments on the application:

• It's just a *very rough* draft version - there's much to improve there (setup CDK & renderer template, bundle resources, review code, etc). I can work on it more, the idea was to provide example very quickly.
• One of the requirements of RF AJAX is that A4J.Ajax.Submit is not used directly, but via Java API. This guarantees compatibility between versions.
• I decided not to render just JSON output, because this will break messages and alike components. Instead of that, JSON data is passed as special part of AJAX response together with HTML for updated components.
• Usage of jQuery.AJAX can break some RF features like queuing, so it makes sense to use built-in AJAX.

How are the event listeners fired and attached?

Can you please clarify the question?

During event editing it will be resized and dragged. Appropriate events should be fired, but I guess only in ajax mode. So if mode is set to non-ajax should events be submitted? If so then when?

Usually we provide event handler attributes that user can define himself. In this case, it's easy for him to add AJAX by defining a4j:support component for this event.

[blabno]

Hi Nick,

Great example! I have questions:

1. Why rich components sometimes use templates and sometimes renderers are written by hand?
2. Your decision on not rendering JSON is fine for me. I was thinking about the same (sending date changed event and getting back data from response).
3. How are the event listeners fired and attached? I need clarification on JSF mechanism of firing and dispatching events. What params are required for JSF to understand it needs to fire some event? When and by whom the events are fired? Is event and action the same? If component sends ajax event, does it get response, and is there "data" attached?
4. As to JavaScript...fullcalendar has tons of options that can be passed. All as JavaScript arguments. So we need to pass them to the RichFaces.FullCalendar.
   • What do we do with internationalization? Do we provide tag parameters like "monthNames" that accept list of translated names? Or maybe comma separated string?
   • FullCalendar has API that allows user to create event on the client side. How do we synchronize it with server state? Should we fire event and check if datamodel accepts the event? We could use "eventRender" callback to prevent adding unaccepted event.
   • Do we provide facade for JavaScript API and document it or do we redirect developers to fullcalendar docs?
5. FullCalendar allows some options to be customized depending on view mode. It uses View Option Hash. Should we provide 10 variations of those options i.e. dragOpacityMonth,dragOpacityAgendaDay,dragOpacityBasicDay,dragOpacityAgenda,dragOpacityBasic,etc? That would cause our component to have 100 attributes.
6. If we have some enumerable attributes like mode ("ajax","client","server"), do we operate just on strings, or should we create enums. Even if we stay with strings, how can we validate the values?
7. Some attributes like styleClass should not be populated by developer's java code, but on facelet, so I propose creating "rich:scheduleEvent" component that would be a child of schedule component and would provide appropriate binding, i.e.: <rich:sheduleEvent styleClass="importantStuff" rendered="#{event.isMyBirthday}"/>
8. What name do we give to the component, schedule or fullcalendar?

How do you want me to contribute? Send patches?

[jbalunas]

Hi Bernard,

Let me address the contributing quesion tonight, and then I'll take a closer look at the rest of the post as soon as I get through my growing TODO list :-) 

As I mentioned in the other growl thread - first we need you to sign the CLA https://cla.jboss.org/ so we can use you code.

Next, for now, I think that patches are the best way, but as with most open source projects, after some patches we can talk about opening up commit rights to you directly :-)

Ideally we would be targeting the 4.0.X branch with any new updates.  But I know you are more comfortable with 3.3.X for now.  Our goal is to get the 4.0 build cleaned up, and then post some articles and blogs on how to create your own components and integrate with the 4.0 build system and process.  I think you might be a great candidate for that when it is time.

I'll post some other comments on the components soon, but Ilya and Nick are the best :-)

-Jay

[blabno]

Created JIRA issue https://jira.jboss.org/jira/browse/RF-8627 and signed CLA.

[jbalunas]

• I highly vote for splitting the current calendar into two components - calendar input and scheduler.

Yes this is a requirement.  It is far more than a variant on the calendar and have very different needs.

• Scheduler should be encoded at server side instead of building at client as for 3.3.x - that will allow highly customize the content cells (e.g. current design could not support iterations inside.)
• From customization points of view - initially i think you should review current calendar customization points(at least at base ones) Need to doublecheck if the script plugin you proposing really fit the needs. If it would not allow some customization - it should be rewritten/extended. But component functionality should not be limited just because we want to use some existent client side widget.
  • later it highly possible that we will want to extend it more after review.

I agree here, we wan to be careful not to just repackage 3rd party widgets into components.  This does allow to quickly create components I know.  But it also means that you are limited by what the 3rd party component can do, and are reliant on it for fixes if something is broken.

I have no problem prototyping and researching 3rd party components, but I think one of RichFaces strengths is its customizations, and ability to support and maintain quality.

[jbalunas]

Bernard Labno wrote:

• What do we do with internationalization? Do we provide tag parameters like "monthNames" that accept list of translated names? Or maybe comma separated string?

Internationalization - ideally this should be populated via resource bundles on the server, and set during rendering.  This way we can use the language settings from form the browser, or set from server based on available content.

Bernard Labno wrote:

• FullCalendar has API that allows user to create event on the client side. How do we synchronize it with server state? Should we fire event and check if datamodel accepts the event? We could use "eventRender" callback to prevent adding unaccepted event.

It would be great to handle that like any other faces validation, but not sure of the details of the widget.

Bernard Labno wrote:

• Do we provide facade for JavaScript API and document it or do we redirect developers to fullcalendar docs?

When we do use 3rd party libraries we should provide a facade to them, incase we want to switch out the implementation later.

[jbalunas]

Great!  I saw that it and accepted it.  Not the jboss.org lead will approve it.

[ilya_shaikovsky]

Why rich components sometimes use templates and sometimes renderers are written by hand?

talking about 3.3.x - some parts of components required complex logic which not looked good placed in numerous scriptlets and copy/pasted much times in order to output according to the conditions from scriptlets.

How are the event listeners fired and attached? I need clarification on JSF mechanism of firing and dispatching events. What params are required for JSF to understand it needs to fire some event? When and by whom the events are fired? Is event and action the same? If component sends ajax event, does it get response, and is there "data" attached?

You should pass some parameter and process it at decode phase in order to rise event when need.

• What do we do with internationalization? Do we provide tag parameters like "monthNames" that accept list of translated names? Or maybe comma separated string?

I would prefer 3.3.x way where such parameters was configured using application bundle as Jay mentioned. But yes ideally some basic attributes needed. (e.g. current calendar could have locale defined with the other value than app current locale)

FullCalendar has API that allows user to create event on the client side. How do we synchronize it with server state? Should we fire event and check if datamodel accepts the event? We could use "eventRender" callback to prevent adding unaccepted event.

Yes, event like ValueChangeEvent(naming to be changed) shoud be fired at server side and contains data for event. B.t.w. it should be closely tied to scheduler model which could define initial restrictions or constraints for the events.

Do we provide facade for JavaScript API and document it or do we redirect developers to fullcalendar docs?

Agree with Jay. It will be best to use facade because if we will ever need to change base script - it would be possible to done it more smoothly.

FullCalendar allows some options to be customized depending on view mode. It uses View Option Hash

. Should we provide 10 variations of those options i.e. dragOpacityMonth,dragOpacityAgendaDay,dragOpacityBasicDay,dragOpacityAgenda,dragOpacityBasic,etc? That would cause our component to have 100 attributes.

I'm thinking about something like we already done in rich Editor (check ref guide) - usage of configuration files(properties or JSON) and/or parameters. (our new a4j:hashParam tag would fit here great ) And I think in other case there could really be more than 100 options and that not looks good.

If we have some enumerable attributes like mode ("ajax","client","server"), do we operate just on strings, or should we create enums. Even if we stay with strings, how can we validate the values?

It's came from 3.1.x when we can't use enums because of JDK 1.4 support.

Some attributes like styleClass should not be populated by developer's java code, but on facelet, so I propose creating "rich:scheduleEvent" component that would be a child of schedule component and would provide appropriate binding, i.e.: <rich:sheduleEvent styleClass="importantStuff" rendered="#{event.isMyBirthday}"/>

I really like the idea of children components/facets approach for creation of various events/.. representations - is really usefull in order to create really flexible components.

What name do we give to the component, schedule or fullcalendar?

I prefer schedule.

Sorry, need to admit that I not looked closelly to the widget itself but will do it asap as time permit. Because it's really important to start with some design from the beginning in order not to make "rewrite" descisions if some not available customizations/possibilities will appears later. :/

[ilya_shaikovsky]

FullCalendar allows some options to be customized depending on view mode. It uses View Option Hash

. Should we provide 10 variations of those options i.e. dragOpacityMonth,dragOpacityAgendaDay,dragOpacityBasicDay,dragOpacityAgenda,dragOpacityBasic,etc? That would cause our component to have 100 attributes.

Some attributes like styleClass should not be populated by developer's java code, but on facelet, so I propose creating "rich:scheduleEvent" component that would be a child of schedule component and would provide appropriate binding, i.e.: <rich:sheduleEvent styleClass="importantStuff" rendered="#{event.isMyBirthday}"/>

B.t.w. looking once more - I believe that idea from second quote - will solve problem from the first well

[blabno]

I would prefer a component with attributes in stead of parameters (if something changes over versions than IDE will tell me that no such attribute exist).

What we could do is to provide further nested components:

rich:scheduleMonthView

rich:scheduleBasicWeekView

rich:scheduleBasicDayView

rich:scheduleAgendaDayView

rich:scheduleAgendaWeekView

Those components would hold all those variations of attributes. This way we will keep attributes safe, and not too many in single component.

[ilya_shaikovsky]

yes! That's completelly what I meant in my last comment.

[blabno]

Ok, I'm almost there with implementation. Now, i'm working on event listeners. When item is moved or resized we can fire appropriate event. I've done this by queueing special event in decode method of renderer. Then in the component I check for itemMovedListener attribute which should be a method binding and invoke it. Questions:

1. should event be passed to such method? following data should be passed:dayDelta,minuteDelta,allDay and some reference to event
2. do we pass eventId or target object fetched from dataModel?
3. what events should we broadcast? itemMoved,itemResized,itemSelected?
4. I've seen in tree component that in tree.xml there are also <listener> definitions. What do they do?

[nbelaevski]

should event be passed to such method? following data should be passed:dayDelta,minuteDelta,allDay and some reference to event

what events should we broadcast? itemMoved,itemResized,itemSelected?

Yes, event should be passed. You can create special event class to hold all data that's specific to that event.

This is really dependent on how component interacts with server: directly via built-in AJAX or being wired via a4j:support, but there can be several events, e.g. DnD components emit several events: DragEvent, DropEvent, then ActionEvent.

do we pass eventId or target object fetched from dataModel?

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

I've seen in tree component that in tree.xml there are also <listener> definitions. What do they do?

They're adding MethodBinging properties for these events and also generate standalone listener tags.