Hi Ed,
Am 06.06.2012 um 15:09 schrieb Edward Burns:
>>>>>> On Mon, 4 Jun 2012 18:20:33 +0200, Frank Caputo <frank_at_frankcaputo.de> said:
>
> FC> Hello EG,
> FC> this email has 3 SECTIONS. Find the proposal at the end.
>
> FC> SECTION: Answer to Ed's question.
>
> FC> I can answer the question with a simple example. Suppose the
> FC> following simple form where you have a dynamic fieldset and a
> FC> dynamic legend rendered on ajax requests.
>
> FC> <h:form>
> [...]
> FC> </h:form>
>
> FC> If we added an attribute elementName to the panelGroup, we could
> FC> convert the fieldset to <fieldset name="twoFields" id="twoFields"
> FC> jsfc="h:panelGroup" elementName="fieldset"> and the legend to
> FC> <legend id="legend" jsfc="h:panelGroup" elementName="legend">.
>
> But why do we need UIComponent nodes in the view for both the <fieldset>
> and the <legend> elements? With a composite component for this, there
> would be a top-level UIComponent node corresponding to the whole chunk
> of markup, and it would have UIInput children for the <h:inputText> and
> <h:inputSecret> markup, instrumented with the appropriate ajax
> behavior. Why is that not good enough?
>
> FC> If we wanted to do this with composite components, we would have to
> FC> write 2 composite components, which would be quite complex, to
> FC> achieve this simple behavior.
>
> Please pardon my slowness on this, but I don't see the need for two
> composite components.
In my example I wanted to render ONLY the legend tag on keyup on the inputText and the whole fieldset on blur of the inputSecret.
The problem is, that you need a component for everything in the render list corresponding to a clientside element. So you would either need 2 composite components or you must wrap the legend and the fieldset inside of a panelGroup (HTML developers hate this), to achieve this currently.
> FC> Since the generic dynamic element behaves exactly the same like the
> FC> panelGroup, I still propose to simply add the attribute elementName
> FC> to h:panelGroup.
>
> FC> I think, this is a very simple change, having the passthru
> FC> attributes, and gives the HTML developers a good experience.
>
> FC> SECTION: alternative
>
> FC> We could do copy and paste and invent a new element which behaves
> FC> like h:panelGroup with an additional attribute elementName.
>
> FC> SECTION: proposal
>
> FC> 1. Add the attribute elementName to the VDL doc of h:panelGroup with the following constraints:
> FC> - name: elementName
> FC> - required: false
> FC> - request-time: false
> FC> - type: javax.el.ValueExpression (must evaluate to java.lang.String)
>
> FC> - description: The name of the rendered HTML element. If layout is
> FC> also specified, elementName takes priority.
>
> AS> What did you think of the idea that Imre and I discussed - ie. doing
> AS> something like:
>
> AS> <legend id="legend" jsfc="h:element">
>
> AS> Or maybe some simplification of this, eg:
>
> AS> <legend id="legend" jsfc="true">
> AS> <legend id="legend" jsfc="jsfc">
>
> AS> If we go this route we would need to have some more discussion about how
> AS> to handle component-level attributes (eg. rendered, id) vs pass through
> AS> attributes (eg. everything else).
>
> Well, we need to have that discussion anyway. That's why I'd really
> rather solve 1089-PassThruAttributes first before even talking about
> 1111-PassThruElements, but it seems folks are more excited about
> 1111-PassThruElements.
>
> I strongly oppose overloading h:panelGroup for this. If we must have
> passthru elements, and I'm still not convinced we need them, let's have
> h:element. As to the question of "what UIComponent?" it would be
> UIPanel and we would define a new renderer type: javax.faces.Element.
This would be OK for me.
> FC> I'd like to specify some changes to the jsfc syntax, but I can't
> FC> find where the actual behavior of the jsfc syntax is specified. Can
> FC> anybody give me a hint?
>
> The jsfc feature crept in when we adopted Facelets, but it was never
> given the true attention it deserved because not all EG members liked
> it. I do like it because it gives me a counter to Wicket fans. In any
> case, 1111-PassThruElements is our opportunity to cleanup and correctly
> specify the jsfc feature. The only reference to the feature I could
> find in the spec is in the VDLDoc for ui:repeat and ui:remove.
>
> https://maven.java.net/service/local/repositories/snapshots/archive/javax/faces/javax.faces-api/2.2-SNAPSHOT/javax.faces-api-2.2-20120606.080027-1-javadoc.jar/!/vdldocs/facelets/ui/repeat.html
> https://maven.java.net/service/local/repositories/snapshots/archive/javax/faces/javax.faces-api/2.2-SNAPSHOT/javax.faces-api-2.2-20120606.080027-1-javadoc.jar/!/vdldocs/facelets/ui/remove.html
OK. Then let's give it the attention now. I think it all competitors have something like the jsfc syntax (eg tapestry with jwcid).
Cheers,
Frank
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/
> | 29 Business days til JSF 2.2 Public Review to EG
>