This is part of a larger set of pages - RichFaces 4.0 Release Center

This document will be a store for some high level thoughts on components changes during moval. Please do not edit this document to promote the features you need. Such changes could be reverted without any discussions. Use RichFaces development space discussions in order to propose new feature or highlight some announced but non-implemented in 3.3 which you mean vital for component future version.

Questions to be answered before decision to move the component to 4.x milestone plan

We need to decide:

• if the component should be implemented as an actual component or as just composite component
  • rich:panel, spacer, separator, messages... are good candidates to be provided as composite components. (Or we do not plan to implement something in this  way?)
• if the component has open questions for markup restrictions/different solutions or client code implementation options which will have huge impact on the development. Then such component should be postponned till corresponding discussion
  • contextMenu, calendar and etc.. uses macrosubstitutions from 3.3.x and we talked about the problems in such approach during f-2-f. So seems need to continue the discussion before deciding to implement this
  • tabPanel, panelBar and so on has some restrictions to be finalized in order to be implemented using semantic markup standards.
• Does CDK could be easilly used to create component. Or some postponed CDK features(if will still exist) should be implemented before for more easy development.
• Component requirement should not lacks two major points which we not highly carried about before:
  • 508 compliant
    • http://www.section508.gov/index.cfm?FuseAction=Content&ID=12#Software
    • http://www.section508.gov/index.cfm?FuseAction=Content&ID=12#Web
  • http://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
  • complete JS api

Facet and attribute names.

Some component facet and attribute names has horrible and uncertain syntax. We can provide more correct syntax, but there is problem: If we change these names for RichFaces 4.0, migration would require developers to rewrite all pages in the application. The possible solutions are:

1. Left all existing stuff as is.
2. Provide aliases for old names in the taglibs with exiting URL's and introduce new taglibs for changed ones only.
3. Revise names and create migration tool which could rename old names on pages.
4. Revise names andprovide migration guide.

Addtional Iteration tag to add component childs dynamically

We have many request for component to create some component childs dynamically. Currently the answer is c:forEach usage.

<rich:tabPanel>
   <c:forEach>
      <rich:tab>
         ...
      </rich:tab>
   </c:forEach>
</rich:tabPanel>

The same valid for panelBar, menus...

Now we need to decide:

• Is JSTL tag usage  fit our needs?
• Should we improve a4j:repeat to support such usage?
• Should we write separate tag for such case

BusyBehavior

<draft>

<h:commandButton ...>
    <f:ajax .../>
        <rich:busyBehavior value="Processing..." event="onclick" .../>
</h:commandButton>

busyBehavior could also have nested tags instead of setting value for more complex output.  Also the event would be optional, but instead of always showing the busy output, you could specify it for a specific event.  We would probably also want a "for" attribute so that you can specify which behavior this busyBehavior triggers for.  This would be good if the button had both an onclick and mouseover.

dataTable Component Review/Consolidation

Currently have 3 tree components, are they all needed, can they be merged

• wiki page for initial requirements and thoughts.

DataLists

It seems that dataList components could be also unified into one component which will have type attribute with next values:

• ordered
• unordered
• definition

Tree Table

To be considered when reviewing table components.

<add links to wiki, forum>

Short Overviews of the components RFC's/problems (to be expanded in concrete design pages)

Ouput and Menu Components

• panel
  • candidate for just composite component implementation
• Spacer, separator
  
  • candidates for just composite component implementation
• tabPanel
  • Review popular possible extensions component features
    • multilined tabs list
    • FireFox-like control for chossing betwen tabs which not displayed at tab line because of sizes limitation
    • sides/bottom tabs placement
    • closure built-in functionality
    • lazy mode for tabs (ajax mode which changed to client after tab loaded once)
  • Need to finalize discussion on semantic markup limitations for the component
  • Component very important to be 508 complaint
  • improvements in positioning of tabs customization
  • possible redesign of current tags set/page definitions
    • currently many options defined at tab actually defines at the content panel and it confuses customers(e.g. tab id problem. tab control can't be reREndered explicitly).
    • some options could not be added at all to tab controls itself.
  • improvements related to failed validation/conversion and it's affect to switching states.
• modalPanel
  • Design should be reviewed. Need revise the possibilities to make it more lightweight again.
  • Panel should became just popupPanel instead of modalPanel and modal functionality should became configurable.
• togglePanel
  • We need to add different type of toggleControls rendering. currently only link could be used.
  • Need to discuss of changing child definitions way from facet to child components. Thats way will allow more clear dynamical component creation(using the same iteration tag as described above).
  • improvements related to failed validation/conversion and it's affect to switching states.
• Simple toggle panel
  • ...
• dropDownMenu/contextMenu
  • Iteration tag to create items dynamically.
  • macrosubstitutions used in contextMenu. So the component should wait for discussion on this topic results to be moved in 4.0.
• panelBar
  • Iteration tag to create bars dynamically.
• panelMenu
  • Iteration tag to create items dynamically.
• Tooltip
  • Need to revise and simplify component
    • I think there is no place for ActionEvent in this component
    • Something similar to macrosubstitutions(not supoprted now at all) should be added to functionality after common discussion about them
  • Revise possibility to use  some js Objects shared instances instead of craetion the tooltip object everywhere where it's mentioned.
• ToolBar
  • Provide semantic markup
• ProgressBar
  • Seems requires just code clean up and review.

Inputs/Selects

Components which is important for our community but has to be carefully redesigned/extended according to numerous RFC's forum posts(selects design, shared js objects instances and so on):

• inplaces
  
  • there we should review current markup as it was causes many issues during component usage
  • we should think about implementation which shares the base inplace instance in order not to create js objects for all components one the page (case with huge tables with components)
  • Need to extend the list (secret, textarea) as possible.
• suggestion/comboBox
  • Select based implementations. We should care about such usage in the components or to create separate components for input suggestions and select ones.
  • The same problem with possible using of some js Objects shared instances.
  • semantic markup questions opened. (e.g. suggestion represent real table in popup so seems should not be redesinged)
  • suggestion component should became real input instead of helper widget which attaches to some standard input on the page.
• calendar
  • The same problem with possible using of some js Objects shared instances.
  • the component seems not required div based design as functionally it's real table of dates.
  • macrosubstitutions usage approach review should be completed before.
• slider/spinner
  • seems less problematic components but requires the markup/js code to be reviewed carefully because was designed for 3.0 initial release and could lacks some current coding conventions.
  • semantic markup for them to be investigated designed
• Editor - as it fully based on the thirdparty widget - seems should be just moved carefully into 4.x codebase without problems
• FileUpload
  • Design seems should be revised additionally. Many customers was not happy with our complex design and used css tricks to override it to just simpliest one. (Maybe some presets creation)
  • FireFox now allows sending files using xmlhttpRequests. We should consider such points during design.
• ColorPicker - already based on jQuerry widget. So seems could be just moved carefully to 4.0 codebase.
• Shuttles/PickList components
  • Also seems div based markup for the components also not required because them represents real tables.
  • Review the possibility to remove required Converters/Object hashCode/equals method redefinitions.
  • lists customization possibility was not done in 3,3, but should consider in 4.x