[ 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
> Added XMLMenuModel
> ------------------
>
> Key: ADFFACES-15
> URL: http://issues.apache.org/jira/browse/ADFFACES-15
> Project: MyFaces ADF-Faces
> Issue Type: New Feature
> Environment: software platform
> Reporter: Gary Kind
> Attachments: menu-process-demo.zip, menu-process.zip, trunk.patch
>
>
> Additions to MyFaces ADF-Faces to allow easy creation of menus (navigation
> and tabbed navigation) for .jspx pages using ADF-Faces UI components. Menus
> are specified in XML Metadata files. In the .jspx page menu items are
> af:commandNavigationItems nodestamped inside of location-specific facets that
> are children of af:panelPage. The Menu Model managed bean that processes
> the metadata files, along with the navigation-rules/cases are specified in
> the faces-config.xml file.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
