[ http://issues.apache.org/jira/browse/ADFFACES-15?page=all ]

Simon Lessard updated ADFFACES-15: ----------------------------------

Attachment: menu-process.zip menu-process-demo.zip

I added one model of my own. It was used mainly for demo and some part of it was
used in a true project.

I could not create a .patch because the source files are in a new folder and SVN
would not let me create a patch under those conditions. I did not grant Apache
license for now since I would like to know if you're interested in it first. For
the same reason, I didn't put English comments in yet.

The library provides models for both mnus and processes

The semantic is:

<menuNode> ::= <menu> | <menuItem> <menu> ::= <menuNode>* <menuItem> ::= viewId+ (more or less)

<processNode> ::= <process> | <processStep> <process> ::= <processNode>* <processStep> ::= viewId+ (more or less)

A menu can be defined as a managed bean with managed properties, for example:

<managed-bean> <managed-bean-name>menuRoot</managed-bean-name>
<managed-bean-class>org.apache.myfaces.adf.model.impl.menu.Menu</managed-bean-class> <managed-bean-scope>application</managed-bean-scope> <managed-property> <property-name>items</property-name> <property-class>java.util.List</property-class> <list-entries> <value-class>org.apache.myfaces.adf.model.impl.menu.MenuNode</value-class> <value>#{menuItem1}</value> <value>#{menuItem2}</value> </list-entries> </managed-property> </managed-bean>

<managed-bean> <managed-bean-name>menuItem1</managed-bean-name>
<managed-bean-class>org.apache.myfaces.adf.model.impl.menu.MenuItem</managed-bean-class> <managed-bean-scope>none</managed-bean-scope> <managed-property> <property-name>label</property-name> <property-class>java.lang.String</property-class> <value>Item 1</value> </managed-property> <managed-property> <property-name>viewId</property-name> <property-class>java.lang.String</property-class> <value>/pages/menus/menuItem1.jspx</value> </managed-property> </managed-bean>

Inside an <af:page> one only have to use:

<af:page value="#{menuRoot.model}" var="item"> <f:facet name="nodeStamp"> <af:commandNavigationItem text="#{item.label}" action="#{item.execute}" actionListener="#{item.processAction}" disabled="#{item.disabled}" icon="#{item.icon}" immediate="#{item.immediate}" rendered="#{item.rendered}"/> </f:facet> </af:page>

#{item.execute} will, in order: 1) Check if there was an outcome specified, if so return it 2) Check if there was a method binding specified, if so call it and returns its
return value 3) Check if a viewId was specified, if so navigate to it 4) Return null.

Also, menu nodes allow most properties, except JavaScript for now, in 3
different modes: 1) static value, for example: <managed-property> <property-name>label</property-name> <property-class>java.lang.String</property-class> <value>Item 1</value> </managed-property>

2) dynamic value evaluated once at bean creation, for example: <managed-property> <property-name>label</property-name> <property-class>java.lang.String</property-class> <value>#{bundle['item.1.label']}</value> </managed-property>

3) dynamic value evaluated everytime the property is read, more than often
during render response phase, for example: <managed-property> <property-name>labelExpression</property-name> <property-class>java.lang.String</property-class> <value>bundle['item.1.label']</value> </managed-property>

3rd mode require a modified property name with the "Expression" suffix. Also,
the expression is not an EL one, it does not have the #{} delimiter. Another
reason why I did not put the comments in yet is also this point. I was wondering
if it would not be better to make the 3rd mode use the same property name as the
other two, but with a different EL synthax, like %{} for example, to bypass JSF
automatic EL evaluation.

Processes work pretty much the same way, but they also have some additional
flags, among them are: - activeDisabled: if true, the current step will be disabled, preventing the
user to launch validations that way for example. High end users requested that
in a past project.

- visitedImmediate: if true, the already visited steps will be marked immediate
and thus won't launch valid nor save the data already filled.

- mode: supports 8 modes defined by an Enum: BACKTRACK : Allows the user to navigate backward only using the train BACKTRACK_PLUS_NEXT : Allows the user to navigate backward as well as toward the
next step using the train MAX_VISITED : Allows the user to navigate to any step he already visited using
the train MAX_VISITED_PLUS_NEXT : Allows the user to navigate to any step he already
visited using the train as well as the next step NEXT_ONLY : Allows the user to navigate to the next step only using the train NO_NAVIGATION : Prevent the user from navigating by using the train (train
become only a graphical display of advancement) PREVIOUS : Allows the user to navigate to the previous step only using the train PREVIOUS_PLUS_NEXT : Allows the user to navigate to the previous step and next
step using the train

Any comments/ideas?

Regards