Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.0.0-beta-1
-
None
Description
The tr:forEach tag has issues when trying to use component references and trying to keep the component state in sync with the items in a list. It also does not support Maps like the c:forEach tag does.
I seek to improve the forEach tag in Trinidad, and propose that JSF/JSTL does something similar so that user's can really use the for each tag without issues. Some of the for each problems are described in my blog:
http://drewdev.blogspot.com/2008/08/cforeach-with-jsf-could-ruin-your-day.html
I propose to address each of the issues with the JSP tag.
First, reliable component references:
<tr:forEach var="item" items="#
<tr:panelGroupLayout id="pgl1" layout="horizontal">
<tr:inputText id="it1" label="Enter value:" value="#{item.text}" autoSubmit="true" />
<tr:outputText id="ot1" value="Value is: #{item.text}" partialTriggers="it1" />
</tr:panelGroupLayout>
</tr:forEach>
The problem is that the author intended the output text component to partially updated by the sibling input text when it changed value, but that is not the result. Instead, the partial triggers is always "it1", but the generated input text components are "ot1", "ot1j_id_1" and "ot1j_id_2". The result is that the output text components all partially update only when the first input text is changed.
Another problem is that the indexed value expressions and the var status map that is put into the variable mapper by the for each loop is static. Take the following example:
<tr:panelGroupLayout id="pgl1" layout="scroll">
<tr:forEach var="item" items="#{myBean.items}
" varStatus="vs">
<tr:outputText id="ot1" value="This is the last item in the list: #
. Item #
{item.text}." />
</tr:forEach>
</tr:panelGroupLayout>
Say during the first pass, the items in the list are A, B and C and the page would look like this:
This is the last item in the list: false. Item A.
This is the last item in the list: false. Item B.
This is the last item in the list: true. Item C.
Now, consider what the output would be if someone added an object D to the end of the list during invoke application:
This is the last item in the list: false. Item A.
This is the last item in the list: false. Item B.
This is the last item in the list: true. Item C.
This is the last item in the list: true. Item D.
Notice that both C and D think they are the last. The reason is that the UIComponentClassicTagBase will find the components generated for A, B and C during the findComponent call. It will only create a new component for D. When D is created, it will pick up the new variable status map created by the for each tag in its value expressions. Because when three earlier components were build, C was the last item, and the variable status map in their value expressions did not reflect any changes. D gets the correct values since it was just created.
-----------------
I propose to reduce any work required by page developers to implement the for each loop with re-ordering support (avoid having to use immediate EL in the ID attribute) and fix the issues above.
The proposal is that Trinidad Tag based components (those components created by UIXComponentELTag) will be able to have key-based IDs automatically generated as a result of being in a for each tag. So consider this example:
<tr:forEach var="item" items="#
{bean.items}" varStatus="vs">
<tr:inputText id="it1" value="#
<tr:outputText id="ot1" value="Value is: #{item.value}
"
partialTriggers="it1_${vs.key}" />
</tr:forEach>
In this code, the IDs of the components would automatically pick up the item key. The item key would be stored on the var status. For List this key would simply be the index, for Map it would be the map key and CollectionModel would use the row key. UIXComponentELTag could check to see if a parent tag desires to alter the component IDs, which in this case, the for each would. With that set, the tags would alter the component IDs to append the key. For example, "_" + key would be appended to each component ID (it1 would become it1_A if the key were "A").
The for each tag would set the key into the variable mapper so that, instead of indexes, the key would be used to evaluate the EL with the limitation that the key would be the index for List, in which the current behavior would be retained of the component state staying with the index rather than with the object.
Due to the fact that the JSP does not perform any component reordering, the org.apache.myfaces.trinidad.change.ReorderChildrenComponentChange component change class can be use to alter the component order and also notify the component change manager of the reordering. This would require users that wish to reorder the items in the list to ensure to both re-order the list as well as reorder the components by applying a component change.
Changes to UIXComponentELTag
Due to the fact that UIComponentClassicTagBase is a JSF class that we cannot modify, in order to fix the tr:forEach bugs, we need to work with what we can change. We will want to follow this up with proposed changes to the JSF and potentially the JSTL specifications to be able to make this type of functionality standard.
Since UIXComponentELTag extends UIComponentClassicTagBase, it can call protected methods to alter the ID of the tag. With the altering of the tag ID, the UIComponentClassicTagBase will produce different component IDs. In order to pull this off, there needs to be a defined contract between the for each tag and the Trinidad component tags. This contract could be done with static methods on UIXComponentELTag:
Proposed methods to be added to UIXComponentELTag
/**
- Push a component ID suffix onto the page context to append to component IDs generated by
{@link UIXComponentELTag}
.
- This will append the suffix on all components up to a and including the text naming container.
- @param pageContext the JSP page context
- @param suffix the suffix to append to component IDs
*/
public static void pushComponentIdSuffix(PageContext pageContext, String suffix)
{
...
}
/**
- Pop the last component ID suffix added to the page context.
- @see #pushComponentIdSuffix(PageContext, String)
- @param pageContext the JSP page context
*/
public static void popComponentIdSuffix(PageContext pageContext)
{
...
}
The ForEachTag would then call these methods before and after the body processing respectively. The idea would be that if a UIXComponentELTag created a naming container, it would clear any suffixes for children of the naming container. This is because the IDs would already be unique in the naming container, and there would be no reason to modify them, and it would also stop these changes from affecting any IDs inside of included pages. The push/pop method would be used to support a stack usage. This way, if nested for each tags are present, multiple suffixes would be added to ensure that the IDs in one for each tag would conflict with another's.
As this would be a documented behavior, users could leverage this API to ensure that their component references (like the partialTriggers attribute) point to the correct component.
Changes to ForEachTag
The for each tag, with this proposal, would need to be modified to call the new methods of UIXComponentELTag in doStartTag and doAfterBody functions.
The tag will need to change to provide dynamic value expressions for the var status and the var so that changes to the items will not break EL. This would involve using the key as a reference instead of an index for non list based items. The var status would need point to a component tree based attribute that could be updated in each request. For example, this would allow new items to be added, and the last attribute to correctly reflect that new state.
The for each tag would be change to support Map and CollectionModel as well, and adding the key as a valid attribute on the varStatus object.
Optionally skip this for List and array
If we did not implement the ID suffixing for List (and arrays), existing applications would not be affected. This is one consideration to have to ensure that backwards compatibility is maintained. Another alternative is to use a web.xml configuration parameter and only introduce the ID suffixing when the web XML parameter has enabled it for lists and arrays.
Attachments
Issue Links
- depends upon
-
TRINIDAD-2318 Support EL embedded in a literal partialTriggers attribute
-
- Resolved
-