>>>>> 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.
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.
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
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