M5 planning

This document will describe the migration of calendar component.

information from 3.3.x:

references:

http://docs.jboss.org/richfaces/latest_3_3_X/en/devguide/html/rich_dragSupport.html

http://docs.jboss.org/richfaces/latest_3_3_X/en/devguide/html/rich_dropSupport.html

http://docs.jboss.org/richfaces/latest_3_3_X/en/devguide/html/rich_dragIndicator.html

http://docs.jboss.org/richfaces/latest_3_3_X/en/devguide/html/rich_dndParam.html

tld:

http://docs.jboss.org/richfaces/latest_3_3_X/en/tlddoc/rich/dragSupport.html

http://docs.jboss.org/richfaces/latest_3_3_X/en/tlddoc/rich/dropSupport.html

http://docs.jboss.org/richfaces/latest_3_3_X/en/tlddoc/rich/dragIndicator.html

http://docs.jboss.org/richfaces/latest_3_3_X/en/tlddoc/rich/dndParam.html

svn

http://anonsvn.jboss.org/repos/richfaces/branches/community/3.3.X/ui/drag-drophttp://anonsvn.jboss.org/repos/richfaces/branches/community/3.3.X/ui/calendar

Related requests and jiras:

list of jira's

Umbrella jira item

High level tasks for M5

• two behaviors to be done
  • dragBehavior
  • dropBehavior
• attaching drag sources to drop zones
  • dragBehavior should provide type attribute
  • dropBehavior should provide acceptedTypes attribute which should support all the same definitions as render and execute does(list of strigs and just string using separators)
• both behaviors should provide value bindings. dropValue and dragValue attributes at corresponding tags.
• dragIndicator component
  • without client substitutions features for M5. just static indicator definition
  • dragBehavior should be pointed to indicator using "dragIndicator" attribute
    • default indicator (component specified and referenced but without any content inside) just bordered div which provides special classes for different states.
    • if drag not defined with any indicator - dragged element clone should be used.
    • child components support in indicator - not for M5.
  • dragged element should be attached to body in order to be placed on top of any components.
    • not customizable
  • without facets as for 3.3.x. I think all the customization points should be solved using default substitutions or customizable macrosubstitutions in future. And we do not need single and multy also in that case. It's easier to support at API/application level than make components depends one on another to take care out of the box.
• Server Side events
  • DropEvent
    • should have information about: dragComponent, dropComponent, dragSource and dropSource(behavior instances). Values could be get from the behaviors instances.
• both drag and drop behaviors should accept parameters - not possible at behavior.
• drop support should provide all ajax attributes and support queueing.
• only drop support should require h:form around it.

Postpone from M5