[jsr344-experts mirror] [jsr344-experts] [1111-PassThroughElements] (was: Pass Through Elements)

  • From: Edward Burns <edward.burns@...>
  • To: JSF Experts <jsr344-experts@...>
  • Subject: [jsr344-experts mirror] [jsr344-experts] [1111-PassThroughElements] (was: Pass Through Elements)
  • Date: Wed, 30 Jan 2013 11:25:01 -0800
  • List-id: <jsr344-experts.javaserverfaces-spec-public.java.net>

>>>>> On Mon, 07 Jan 2013 22:51:18 +0100, =?ISO-8859-15?Q?Michael_M=FCller?= 
>>>>> <michael.mueller@...> said:

MM> Hi Volunteers,
MM> Suppose we have

MM> <input type="submit" id="btn" value="myButton"/>

MM> In the API the reader finds this element should be included into the 
MM> component tree, if prefixed by the sun...JSF namespace, e.g

MM> <input type="submit" jsf:id="btn" value="myButton"/>

MM> Now, let's add an action

MM> <input type="submit" jsf:id="btn" value="myButton" 
jsf:action="#{myBean.myAction}"/>

MM> This action is not HTML5, but JSF specific. I guess, we all know, that a 
MM> couple of attributes should be supported. But how should somebody know, 
MM> who is new to JSF and reads the spec for the first time? Is this 
MM> specification missing, or do I simply havn't seen it?

>>>>> On Wed, 9 Jan 2013 09:21:57 +0100, Frank Caputo <frank@...> said:

FC> it is necessary, that the user knows a little bit about form
FC> handling in JSF. If so, she could simply read the javadoc of
FC> TagDecorator to see the mapping between the HTML tags and JSF
FC> components:
FC> 
https://maven.java.net/service/local/repositories/snapshots/archive/javax/faces/javax.faces-api/2.2-SNAPSHOT/javax.faces-api-2.2-20130104.160953-119-javadoc.jar/!/javadocs/javax/faces/view/facelets/TagDecorator.html

I just committed a revision to the spec PDF that should address this
issue.  Here is the commit log message.

M       preface.fm

- Introduced H2 section "Big Ticket Features" with references to the
  non-normative overview section for each of the three big ticket
  features.

- Group the existing "by functional area" subsections under a new H2
  section titled "Other Features, by Functional Area".

M       integrationWithFacelets.fm
M       applicationIntegration.fm

- Cross References
Sending        applicationIntegration.fm
Sending        integrationWithFacelets.fm
Sending        preface.fm
Transmitting file data ...
Committed revision 1108.

The next PDF rev will have these changes.

>>>>> On Tue, 22 Jan 2013 22:59:29 +0100, Michael Müller 
>>>>> <michael.mueller@...> said:

MM> Frank,
MM> In my opinion I still belive the javadoc is not clear enough at this 
point.

MM> Given
MM> <h:inputText ...>
MM> there is a well defined element for input, which will be added to the 
tree.

MM> Let's move on to pass through
MM> <input jsf:id="param1" type="text"...>
MM> The spec says, add an element to the component tree, if "jsf:" (more 
MM> precise: an element of
MM> "|http://java.sun.com/jsf";)|||is found in the page. Now, we have an 
MM> element of |javax.faces.passthrough.Element within |the tree. Can we add 
MM> an action to it? Or a value? Or whatever?

MM> To get this information, the developer has to examine the class 
MM> TagDecorator. She may discover the <input> mapped to <h:inputText>.

MM> But what happens, if a new element is invented for HTML5?
MM> <newElement jsf:id="myId"...>
MM> Because of jsf:id it will be added to the tree.
MM> Again my questions: Can we add an action to it? Or a value? Or whatever?

MM> Have I overlooked something in spec + javadoc + source? Maybe, let me 
MM> know. But IMHO, the spec/javadoc might be get more detailed here.

>>>>> On Wed, 23 Jan 2013 20:50:21 +0100, Frank Caputo <frank@...> said:

FC> Are you referring to vdldocs/facelets/jsf/tld-summary.html? The text
FC> seems to be incorrect. We should simply delete that section and
FC> refer to TagDecorators javadoc.

I deleted all but the introductory paragraph and linked as you
suggested.

MM> Now, we have an element of javax.faces.passthrough.Element within the 
tree.

FC> No, we have a javax.faces.HtmlInputText within the tree.

MM> Can we add an action to it?

FC> No.

MM> Or a value? Or whatever?

MM> To get this information, the developer has to examine the class
MM> TagDecorator. She may discover the <input> mapped to <h:inputText>.

FC> Right.

MM> But what happens, if a new element is invented for HTML5?
MM> <newElement jsf:id="myId"...>
MM> Because of jsf:id it will be added to the tree.
MM> Again my questions: Can we add an action to it? Or a value? Or whatever?

FC> TagDecorator's javadoc makes clear that you get a jsf:element, which
FC> can't have an action or a value. All possible are attributes are
FC> listed in the vdldocs: vdldocs/facelets/jsf/element.html

MM> Have I overlooked something in spec + javadoc + source? Maybe, let
MM> me know. But IMHO, the spec/javadoc might be get more detailed here.

FC> Do you have an idea, how to clarify this?

I will do so in the new non-normative overview section.

Ed

-- 
| edward.burns@... | office: +1 407 458 0017
| homepage:               | http://ridingthecrest.com/


[jsr344-experts mirror] [jsr344-experts] Pass Through Elements

Michael Müller 01/07/2013

[jsr344-experts mirror] [jsr344-experts] Re: Pass Through Elements

Frank Caputo 01/09/2013

[jsr344-experts mirror] [jsr344-experts] Re: Pass Through Elements

Michael Müller 01/22/2013

[jsr344-experts mirror] [jsr344-experts] Re: Pass Through Elements

Frank Caputo 01/23/2013

[jsr344-experts mirror] [jsr344-experts] [1111-PassThroughElements] (was: Pass Through Elements)

Edward Burns 01/30/2013
Terms of Use; Privacy Policy; Copyright ©2013-2015 (revision 20150626.29986a4)
 
 
Close
loading
Please Confirm
Close