[JBoss JIRA] (RF-11922) Nesting an a4j:actionListener in a composite component results in a java.io.NotSerializableException
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-11922?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-11922:
-------------------------------
Labels: jsf (was: )
> Nesting an a4j:actionListener in a composite component results in a java.io.NotSerializableException
> ----------------------------------------------------------------------------------------------------
>
> Key: RF-11922
> URL: https://issues.jboss.org/browse/RF-11922
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.1.0.Final
> Environment: JBoss AS 7.0.2, mojarra 2.1
> Reporter: Brian Leathem
> Labels: jsf
> Fix For: 5-Future
>
>
> In the code samples below, an a4j:actionListener is nested in a composite component. This results in a java.io.NotSerializableException (stack trace below).
> {code:title=actionComposite.xhtml}
> <composite:interface>
> <composite:actionSource name="button" />
> <composite:attribute name="render" />
> <composite:attribute name="execute" />
> <composite:attribute name="value" />
> </composite:interface>
> <composite:implementation>
> <h:commandButton id="button" value="#{cc.attrs.value}">
> <composite:insertChildren />
> <f:ajax render="#{cc.attrs.render}" execute="#{cc.attrs.execute}" />
> </h:commandButton>
> </composite:implementation>
> </html>
> {code}
> {code:title=actionListener.xhtml}
> <h:form id="form">
> <h:messages id="messages" />
> <h:panelGrid columns="1">
> <demo:actionComposite render=":form:messages" value="Invoke listener method in composite component">
> <a4j:actionListener for="button" listener="#{actionListenerBean.handleActionMethodComposite}" />
> </demo:actionComposite>
> </h:panelGrid>
> </h:form>
> {code}
> {code:title=Stacktrace}
> Caused by: java.io.NotSerializableException: org.richfaces.view.facelets.html.ActionListenerHandler
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164) [:1.6.0_26]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) [:1.6.0_26]
> at java.util.ArrayList.writeObject(ArrayList.java:570) [:1.6.0_26]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
> at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
> at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945) [:1.6.0_26]
> at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469) [:1.6.0_26]
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) [:1.6.0_26]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) [:1.6.0_26]
> at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518) [:1.6.0_26]
> at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483) [:1.6.0_26]
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) [:1.6.0_26]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) [:1.6.0_26]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) [:1.6.0_26]
> at java.util.ArrayList.writeObject(ArrayList.java:570) [:1.6.0_26]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
> at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
> at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945) [:1.6.0_26]
> at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469) [:1.6.0_26]
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) [:1.6.0_26]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) [:1.6.0_26]
> at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1346) [:1.6.0_26]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1154) [:1.6.0_26]
> at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1346) [:1.6.0_26]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1154) [:1.6.0_26]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) [:1.6.0_26]
> at java.util.HashMap.writeObject(HashMap.java:1001) [:1.6.0_26]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
> at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
> at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945) [:1.6.0_26]
> at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469) [:1.6.0_26]
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) [:1.6.0_26]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) [:1.6.0_26]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) [:1.6.0_26]
> at com.sun.faces.renderkit.ClientSideStateHelper.doWriteState(ClientSideStateHelper.java:325) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT]
> at com.sun.faces.renderkit.ClientSideStateHelper.writeState(ClientSideStateHelper.java:169) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT]
> at com.sun.faces.renderkit.ResponseStateManagerImpl.getViewState(ResponseStateManagerImpl.java:135) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT]
> ... 28 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (RF-12730) Render and Oncomplete attributes are not evaluated if command is conditionally excluded from the comopnent tree
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12730?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-12730:
-------------------------------
Labels: jsf (was: )
> Render and Oncomplete attributes are not evaluated if command is conditionally excluded from the comopnent tree
> ---------------------------------------------------------------------------------------------------------------
>
> Key: RF-12730
> URL: https://issues.jboss.org/browse/RF-12730
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core, core
> Affects Versions: 4.2.0.Final, 4.3.0.CR1
> Environment: MyFaces 2.1.6 / Mojarra 2.1.7
> Tomcat 6.0.35 / 7.0.26
> Reporter: Michael Heinen
> Labels: jsf
> Fix For: 5-Tracking
>
> Attachments: onc333.war, onc42.war, RF-12145.zip, zOnc333WithLibs.war, zOnc42New.war, zOnc42WithLibs.war
>
> Original Estimate: 3 hours
> Remaining Estimate: 3 hours
>
> Sample use case:
> The last page of a wizard contains a commandButton with an EL expressions in the oncomplete attribute and in the render attribute.
> This button renders an outer component in order to close the wizard. The button itself is not rendered anymore after clicking it.
> As a consequence the EL expressions of the oncomplete attribute and of the render attribute is not evaluated after the invocation of an actionListener.
> This worked well with richfaces 3.3.3, therefore it's a critical regression.
> I'll attach a sample webApp for richfaces 4.2 and for riochfaces 3.3.3
> Note that the render attribute of f:ajax is evaluated correctly.
> These attributes of the clicked command must be evaluated in phase render response in all cases.
> ----
> {code:title="OncController.java"}
> package com;
> import java.util.Map;
> import javax.faces.bean.ManagedBean;
> import javax.faces.bean.SessionScoped;
> import javax.faces.context.FacesContext;
> import javax.faces.event.ActionEvent;
> @ManagedBean(name = "OncController")
> @SessionScoped
> public class OncController
> {
> private boolean innerShown = true;
>
> private int calls = 0;
> public OncController()
> {
> }
> public boolean isInnerShown()
> {
> return innerShown;
> }
> public void setInnerShown(boolean aInnerShown)
> {
> innerShown = aInnerShown;
> }
>
> public void clear(final ActionEvent ae)
> {
> innerShown=true;
> calls=0;
> }
> public void doIt(final ActionEvent ae)
> {
> final Map<String, Object> requestMap = FacesContext.getCurrentInstance().getExternalContext()
> .getRequestMap();
> requestMap.put("key1", "alert('after actionListener');");
> requestMap.put("key2", "group2");
> calls++;
> }
> public String getOncomplete()
> {
> final Map<String, Object> requestMap = FacesContext.getCurrentInstance().getExternalContext()
> .getRequestMap();
> final String value = (String) requestMap.get("key1");
> if (value != null)
> {
> return value;
> }
> else
> {
> return "alert('before actionListener');";
> }
> }
> public String getRenderIdsRichfaces()
> {
> final Map<String, Object> requestMap = FacesContext.getCurrentInstance().getExternalContext()
> .getRequestMap();
> final String value = (String) requestMap.get("key2");
> if (value != null)
> {
> return ","+value;
> }
> return"";
> }
>
> public String getRenderIdsFAjax()
> {
> final Map<String, Object> requestMap = FacesContext.getCurrentInstance().getExternalContext()
> .getRequestMap();
> final String value = (String) requestMap.get("key2");
> if (value != null)
> {
> return " " + value;
> }
> return"";
> }
>
> public int getCalls()
> {
> return calls;
> }
> }
> {code}
> {code:title="oncomplete.xhtml"}
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:ui="http://java.sun.com/jsf/facelets"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:a4j="http://richfaces.org/a4j"
> xmlns:rich="http://richfaces.org/rich"
> xmlns:c="http://java.sun.com/jsp/jstl/core">
> <ui:composition>
> <h:head><title>Oncomplete test</title></h:head>
> <h:body>
> <a4j:log mode="popup"/>
> <h:form id="myForm">
> Post button rendered:<h:selectBooleanCheckbox id="innerBool" value="#{OncController.innerShown}"/>
> <br/>
> <h:panelGroup id="outer">
> <c:if test="#{OncController.innerShown}">
> <a4j:commandButton value="RichFaces Post"
> actionListener="#{OncController.doIt}"
> render="outer,details#{OncController.renderIdsRichfaces}"
> oncomplete="#{OncController.oncomplete}"/>
> <h:commandButton value="fAJAX Post"
> actionListener="#{OncController.doIt}">
> <f:ajax render="outer details#{OncController.renderIdsFAjax}"
> execute="@form"/>
> </h:commandButton>
> </c:if>
> </h:panelGroup>
> <br/><br/>
> <h:panelGroup id="details">
> oncomplete: <h:outputText value="#{OncController.oncomplete}"/>
> </h:panelGroup>
> <br/><br/>
> <h:panelGroup id="group2">
> calls: <h:outputText value="#{OncController.calls}"/>
> </h:panelGroup>
> <br/><br/>
> <a4j:commandButton value="Clear"
> actionListener="#{OncController.clear}"
> render="myForm" />
> </h:form>
> </h:body>
> </ui:composition>
> </html>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (RF-13023) a4j:queue Functionality gets lost after Submit (with disabled PARTIAL_STATE_SAVING)
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13023?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13023:
-------------------------------
Labels: jsf myfaces partial_state_saving (was: myfaces partial_state_saving)
> a4j:queue Functionality gets lost after Submit (with disabled PARTIAL_STATE_SAVING)
> -----------------------------------------------------------------------------------
>
> Key: RF-13023
> URL: https://issues.jboss.org/browse/RF-13023
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.2
> Environment: MyFaces 2.1.11
> Richfaces 4.3.2.Final.
> Reproducible with Chrome, FF, IE10
> Reporter: Marco Goetz
> Labels: jsf, myfaces, partial_state_saving
> Fix For: 5-Tracking
>
>
> I have noticed that the requestDelay settings or the whole a4j:queue is not working after a page submit.
> When I open the view the requestDelay works fine and 4 seconds after a keyup event in the input field, an ajax request is processed.
> But when I press the commandButton the queue functionality is lost and ajax requests are performed immediately without a delay.
>
> {code:xml}
> <h:body>
> <h:form id="form">
> <h:commandButton value="Button" />
> <a4j:queue requestDelay="4000"/>
> <h:inputText>
> <a4j:ajax event="keyup" ></a4j:ajax>
> </h:inputText>
> </h:form>
> </h:body>
> {code}
>
> The same problem exists when I use <a4j:attachQueue>
> I found out that this issue is related with PARTIAL_STATE_SAVING context parameter in the web.xml.
> I need to disable this paramter otherwise some views won't work correctly.
> If this paramter is enabled the a4j:queue works like it should.
> My web.xml:
> {code:xml}
> <context-param>
> <param-name>javax.faces.PARTIAL_STATE_SAVING</param-name>
> <param-value>false</param-value>
> </context-param>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (RF-11112) PartialViewContext#getRenderIds() implementation returns empty set
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-11112?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-11112:
-------------------------------
Labels: jsf (was: )
> PartialViewContext#getRenderIds() implementation returns empty set
> ------------------------------------------------------------------
>
> Key: RF-11112
> URL: https://issues.jboss.org/browse/RF-11112
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.0.0.Final
> Environment: Win7 x64, Eclipse Helios SR2, JBoss AS 6.0.0 Final, RF 4.0.0 Final.
> Reporter: Bauke Scholtz
> Assignee: Brian Leathem
> Labels: jsf
> Fix For: 5-Tracking
>
>
> During invoke action phase we would like to retrieve a list of partial render IDs for some specific preprocessing (resetting submitted values for the case they're embedded in another form). Those IDs are normally available by {{PartialViewContext#getRenderIds()}}.
> {code}
> PartialViewContext partialViewContext = FacesContext.getCurrentInstance().getPartialViewContext();
> Collection<String> renderIds = partialViewContext.getRenderIds();
> {code}
> This works fine in combination with standard JSF components, such as {{<h:commandLink><f:ajax render="foo"/></h:commandLink>}} However, when a RichFaces/A4J command component is been used, such as {{<a4j:commandLink render="foo" />}}, an empty collection is been returned instead. Debugging learns that the {{ExtendedPartialViewContextImpl}} implementation stores them in {{componentRenderIds}} instead of {{renderIds}} and never returns it on {{getRenderIds()}} method. The {{ExtendedPartialViewContextImpl}} also doesn't seem to use {{renderIds}} in a sensible manner anywhere else.
> I believe that {{componentRenderIds}} really has to be {{renderIds}} instead.
> As far now, we workarounded this by accessing the {{componentRenderIds}} field using reflection.
> {code}
> Collection<String> renderIds = partialViewContext.getRenderIds();
> if (renderIds.isEmpty() && partialViewContext instanceof ExtendedPartialViewContextImpl) {
> try {
> Field componentRenderIds = ExtendedPartialViewContextImpl.class.getDeclaredField("componentRenderIds");
> componentRenderIds.setAccessible(true);
> renderIds = (Collection<String>) componentRenderIds.get(partialViewContext);
> } catch (Exception e) {
> // Handle.
> }
> }
> {code}
> However, this introduced a nasty dependency in our code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (RF-12177) "data-*" attributes in JSF components
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12177?page=com.atlassian.jira.plugin.s... ]
Brian Leathem resolved RF-12177.
--------------------------------
Fix Version/s: (was: 5-Tracking)
Resolution: Out of Date
This is being addressed in JSF 2.2
> "data-*" attributes in JSF components
> -------------------------------------
>
> Key: RF-12177
> URL: https://issues.jboss.org/browse/RF-12177
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component
> Affects Versions: 4.2.0.Final
> Environment: Any
> Reporter: Paul Dijou
> Priority: Minor
> Labels: attribute, html5
>
> Hi there,
> First of all, sorry for all native English speakers, maybe your eyes will suffer from my grammar...
> A few days ago, I tried to use Bootstrap with JSF and faced quite an issue by not having any "data-*" attributes in JSF composents. Since Bootstrap, and more generally HTML5, relies a lot on this type of attribute, I was thinking it would be great to have them in JSF.
> My first tought was to propose the idea to RichFaces but then I aimed directly to JSF spec and here we are : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1089
> Still, if you are okay for it, it would be great to discuss about this issue (maybe during a RichFaces meeting) in order to propose something more documented than just an idea to JSF spec. I could try to do that alone, but having feedback from JSF experts would be really better and result in more precise and clever proposal.
> So far, here are my thoughts about the problem :
> 1) Only one new attribute {{"data"}} in JSF tags but it will create several {{"data-*"}} attributs in the HTML tag rendered depending on its value.
> 2) Using *JSON format* to provide all {{key => value}} pairs. For example :
> {code}data="{key1:'value1', key2:'value2'}"{code}
> will generate {{data-key1="value1" data-key2="value2"}} in the HTML tag.
> 3) *Nesting attributes* is allowed :
> {code}data="{key1:{sub1:'value11',sub2:'value12'}, key2:'value2'}"{code}
> will generate {{data-key1-sub1="value11" data-key1-sub2="value12" data-key2="value2"}}
> 4) Wait, that means there is no way to have both {{data-key1="value1"}} and {{data-key1-sub1="value11"}} since {{"key1"}} key can only have one value : a real value (like {{"value1"}}) or an array for nesting purpose (like
> {code}"{sub1:'value11',sub2:'value12'}"{code}.
> I think the best way to solve this is to have a specific key that will add no suffix even in a nested array. Let's call this key *'nil' or 'null'* or wathever. So
> {code}data="{key1:{nil:'value1', sub1:'value11', sub2:'value12'}}{code}
> would generate {{data-key1="value1"}} {{data-key1-sub1="value11" data-key1-sub2="value12"}}
> Warning : this special key should no accept an array as value. Or conflicts would appears really quickly. Like having :
> {code}data="{key1:{nil:{sub1:'value1'}, sub1:'value2'}}"{code}
> would generate {{data-key1-sub1="value1" data-key1-sub1="value2"}}... Error !
> 5) Of course, *EL is allowed* inside the JSON format. So, this is correct:
> {code}data="{key1:{sub1:'#{bean.subvalue1}',sub2:'value12'}, key2:'#{bean.value2}'}"{code}
> The return type of the EL must be *String*. But it can be plain String for a real value or an array in JSON format for nesting purpose.
> If {{bean.subvalue1 = "value11"}} and {{bean.value2 = "{sub1:'value21'}"}}, then the precedent example will generate : {{data-key1-sub1="value11" data-key1-sub2="value12" data-key2-sub1="value21"}}
> 6) That was the first part. Next, what about a more *Java centric approach* ? "data" attribut could also accept a {{Map<String, Object>}} as value. For each {{Entry<String,Object>}}, it would add the String key as a suffix of "data" and calling {{Object#toString()}} method for the value. Only exception : if {{Object}} is an instance of {{Map}}, then it will nest the {{Map}}. The special key for non-suffix adding could be null value or an empty {{String}}.
> 7) Perhaps, also, try to do combos ! Like having
> {code}data="{key1:#{bean.value}}"{code}
> where *bean.value* is a {{Map<String,Object>}} that should be interpreted as a JSON array for nesting purpose.
> 8) Or combo fusion ! Having the possibility to add several entry point on the "data" attribute, separated by whitespace, before merging them all.
> For exemple, having :
> {code}data="#{bean.jsonArray} #{bean.firstMap} #{bean.secondMap}"{code},
> where {{bean.jsonArray}} is a String with JSON format, and {{bean.firstMap}} and {{bean.secondMap}} are {{Map<String,Object>}}. But it would be open door to unique attribute name conflicts.
> That's all. I'm really looking forward to any feedback or brainstorming in Irc. Maybe, just another idea, if I have time (or anyone else), try to submit some code doing that to RichFaces. It could help people who are using RichFaces 4 but won't be able to migrate to JSF 2.2 yet and still need "data-*" attributes.
> Thanks for reading.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (RF-12177) "data-*" attributes in JSF components
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12177?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-12177:
-------------------------------
Labels: attribute html5 (was: attribute html5 jsf)
> "data-*" attributes in JSF components
> -------------------------------------
>
> Key: RF-12177
> URL: https://issues.jboss.org/browse/RF-12177
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component
> Affects Versions: 4.2.0.Final
> Environment: Any
> Reporter: Paul Dijou
> Priority: Minor
> Labels: attribute, html5
> Fix For: 5-Tracking
>
>
> Hi there,
> First of all, sorry for all native English speakers, maybe your eyes will suffer from my grammar...
> A few days ago, I tried to use Bootstrap with JSF and faced quite an issue by not having any "data-*" attributes in JSF composents. Since Bootstrap, and more generally HTML5, relies a lot on this type of attribute, I was thinking it would be great to have them in JSF.
> My first tought was to propose the idea to RichFaces but then I aimed directly to JSF spec and here we are : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1089
> Still, if you are okay for it, it would be great to discuss about this issue (maybe during a RichFaces meeting) in order to propose something more documented than just an idea to JSF spec. I could try to do that alone, but having feedback from JSF experts would be really better and result in more precise and clever proposal.
> So far, here are my thoughts about the problem :
> 1) Only one new attribute {{"data"}} in JSF tags but it will create several {{"data-*"}} attributs in the HTML tag rendered depending on its value.
> 2) Using *JSON format* to provide all {{key => value}} pairs. For example :
> {code}data="{key1:'value1', key2:'value2'}"{code}
> will generate {{data-key1="value1" data-key2="value2"}} in the HTML tag.
> 3) *Nesting attributes* is allowed :
> {code}data="{key1:{sub1:'value11',sub2:'value12'}, key2:'value2'}"{code}
> will generate {{data-key1-sub1="value11" data-key1-sub2="value12" data-key2="value2"}}
> 4) Wait, that means there is no way to have both {{data-key1="value1"}} and {{data-key1-sub1="value11"}} since {{"key1"}} key can only have one value : a real value (like {{"value1"}}) or an array for nesting purpose (like
> {code}"{sub1:'value11',sub2:'value12'}"{code}.
> I think the best way to solve this is to have a specific key that will add no suffix even in a nested array. Let's call this key *'nil' or 'null'* or wathever. So
> {code}data="{key1:{nil:'value1', sub1:'value11', sub2:'value12'}}{code}
> would generate {{data-key1="value1"}} {{data-key1-sub1="value11" data-key1-sub2="value12"}}
> Warning : this special key should no accept an array as value. Or conflicts would appears really quickly. Like having :
> {code}data="{key1:{nil:{sub1:'value1'}, sub1:'value2'}}"{code}
> would generate {{data-key1-sub1="value1" data-key1-sub1="value2"}}... Error !
> 5) Of course, *EL is allowed* inside the JSON format. So, this is correct:
> {code}data="{key1:{sub1:'#{bean.subvalue1}',sub2:'value12'}, key2:'#{bean.value2}'}"{code}
> The return type of the EL must be *String*. But it can be plain String for a real value or an array in JSON format for nesting purpose.
> If {{bean.subvalue1 = "value11"}} and {{bean.value2 = "{sub1:'value21'}"}}, then the precedent example will generate : {{data-key1-sub1="value11" data-key1-sub2="value12" data-key2-sub1="value21"}}
> 6) That was the first part. Next, what about a more *Java centric approach* ? "data" attribut could also accept a {{Map<String, Object>}} as value. For each {{Entry<String,Object>}}, it would add the String key as a suffix of "data" and calling {{Object#toString()}} method for the value. Only exception : if {{Object}} is an instance of {{Map}}, then it will nest the {{Map}}. The special key for non-suffix adding could be null value or an empty {{String}}.
> 7) Perhaps, also, try to do combos ! Like having
> {code}data="{key1:#{bean.value}}"{code}
> where *bean.value* is a {{Map<String,Object>}} that should be interpreted as a JSON array for nesting purpose.
> 8) Or combo fusion ! Having the possibility to add several entry point on the "data" attribute, separated by whitespace, before merging them all.
> For exemple, having :
> {code}data="#{bean.jsonArray} #{bean.firstMap} #{bean.secondMap}"{code},
> where {{bean.jsonArray}} is a String with JSON format, and {{bean.firstMap}} and {{bean.secondMap}} are {{Map<String,Object>}}. But it would be open door to unique attribute name conflicts.
> That's all. I'm really looking forward to any feedback or brainstorming in Irc. Maybe, just another idea, if I have time (or anyone else), try to submit some code doing that to RichFaces. It could help people who are using RichFaces 4 but won't be able to migrate to JSF 2.2 yet and still need "data-*" attributes.
> Thanks for reading.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months