Hi,
I understand Paul's review and agree that the proposed behavior is not very handy. But the proposal covers all functional aspects of passthrough attributes and gives us the basis for enhancing the jsfc syntax to support the desired one liners and I still believe, we must do it.
Ciao Frank
Am 22.06.2012 um 09:23 schrieb Çağatay Çivici:
> Hi,
>
> I agree with Paul's review, especially;
>
>>> Even if I find it awesome to have pass through attributes in JSF, I can't really find the current draft acceptable from a user perspective.
>
>
> p:placeholder
>
> instead of
>
> f:passThroughAttribute
>
> looks much better and clean.
>
> Regards,
>
> Çağatay Çivici
> Principal Consultant
> PrimeFaces Lead
>
> On 22.Haz.2012, at 05:06, Andy Schwartz wrote:
>
>> Gang -
>>
>> Just wanted to pass along some feedback from Paul Dijou. (Thanks for reviewing this Paul!)
>>
>>> Hi guys,
>>>
>>> Even if I find it awesome to have pass through attributes in JSF, I can't really find the current draft acceptable from a user perspective. It really gives me the feeling it's only half-baked. It does its job, yes, but it's so verbose, so heavy... Let's take a simple example. Here is a classic HTML5 usage of the input:
>>>
>>> <input type="email" placeholder="To..." autofocus="autofocus" multiple="multiple"/>
>>>
>>> How would I write it in JSF with the current proposal? Probably something like that:
>>>
>>> <h:inputText>
>>> <f:passThroughAttribute name="placeholder" value="Email"/>
>>> <f:passThroughAttribute name="autofocus" value="autofocus"/>
>>> <f:passThroughAttribute name="multiple" value="multiple"/>
>>> </h:inputText>
>>>
>>> What can we see here?
>>>
>>> I can't find a way to set the type to "email" (maybe I'm missing the solution). But it would be good that the spec handle the fact that if you write a pass trough attribute (like writting <f:passThroughAttribute name="type" value="email"/>) that collide with a generate one (<h:inputText> should have generated type="text"), the pass through override the generated one.
>>>
>>> In HTML5, my input is one line and auto-closed, in JSF, it's 5 lines, with an opening and a closing to the inputText. Seriously? I'm 100% in favor of supporting pass trough directly inside the JSF component. It will make the code less verbose, more readeable, more HTML5 like... just better. Something like:
>>>
>>> <h:inputText required="true" p:placeholder="Email" p:autofocus="autofocus" p:multiple="multiple" />
>>>
>>> Isn't that so much better? Honestly?
>>>
>>> And since we are at making life easier, you might see that lots of HTML5 attribute have the same name and value (autofocus, multiple, checked, disabled, readonly, ...). Wouldn't it be cool that if a pass through attribute has a name but no value, it takes it's name as value?
>>>
>>> <h:inputText p:autofocus p:multiple/> => <input type="text" autofocus="autofocus" multiple="multiple"/>
>>>
>>> <h:inputText>
>>> <f:passThroughAttribute name="autofocus" />
>>> <f:passThroughAttribute name="multiple" />
>>> </h:inputText>
>>>
>>> => <input type="text" autofocus="autofocus" multiple="multiple"/>
>>>
>>> One more for the road, I know most of the EG members didn't really like it, but it's on the same topic as previous: just making life easier for users so they enjoy coding with JSF instead of using it only because it's what they bosses want. JSON is the standard to pass data in the current web. Ignoring it would be a big mistake in my opinion (for what it worth). When you call a REST service, there is high chances it will give you JSON. When you want to quickly write a "key/value" map, JSON is awesome.
>>>
>>> Right know, by not supporting JSON inside <f:passThroughAttributes> you will only force people who need JSON support to create a parser that will convert a JSON array to a Java Map, and do the conversion in their backing beans. Not hard, just boring. Each time I found something not hard but boring, I think it should have been on the spec so everybody use the same parser and have a standard way to do the same stuff easily.
>>>
>>> Don't get me wrong, I'm a huge fan and user of JSF, I really like the work of the EG group. But when I saw the full discussion about pass through attributes with at least 3 good solutions (<f:passThroughAttribute(s)> tags, namespace to have them directly inside JSF component, JSON support) and that finally only the heavier will go on the spec, I can't prevent myself from asking : why?
>>>
>>> Regards,
>>>
>>> Paul.
>>
>> Andy
>>
>> On 6/20/12 3:00 PM, Edward Burns wrote:
>>> In light of the excellent discussion on this topic, here are the
>>> proposed spec changes for 1089-passThroughAttributes.
>>>
>>> ACTION: Please review this and give feedback by 12:00 EDT Friday. I
>>> really hope you all find it acceptable as is, though.
>>>
>>> SECTION: CHANGE UIComponent
>>>
>>> Remove constant UIComponent.DATA_ATTRIBUTES_KEY. Replace it with a
>>> read-only JavaBeans property "passThroughAttributes". Here's the spec.
>>>
>>> public abstract Map<String, Object> getPassThroughAttributes()
>>>
>>> This method must never return null. This Map is the data structure that
>>> holds passThrough attributes that must be rendered when the component is
>>> rendered. The ResponseWriter is responsible for ensuring these
>>> attributes are rendered correctly. The returned implementation must
>>> support all of the standard and optional Map methods, plus support the
>>> following additional requirements.
>>>
>>> The Map instance is backed by StateHolder and must participate in
>>> partial state saving, if that feature is enabled.
>>>
>>> The Map implementation must implement the java.io.Serializable
>>> interface.
>>>
>>> Any attempt to add a null key or value must throw a NullPointerException
>>>
>>> Any attempt to add a key that is not a String must throw a
>>> ClassCastException.
>>>
>>> SECTION: DELETE f:dataAttribute
>>>
>>> SECTION: CHANGE HTML_BASIC RenderKit overview section
>>>
>>> Delete the section titled "General notes regarding HTML5 support." The
>>> passThroughAttributes feature will be affected with changes on the
>>> ResponseWriter, not the RenderKit.
>>>
>>> SECTION: ADD f:attributes
>>>
>>> Add a new tag in the jsf_core taglibrary for facelets (not JSP). Here's
>>> the spec.
>>>
>>> For each Map.Entry in the Map<String, Object> referenced by the value
>>> attribute of this tag, take the following action. If
>>> Map.Entry.getValue() is a ValueExpression, call
>>> component.setValueExpression(Map.Entry.getKey(), Map.Entry.getValue()).
>>> Otherwise, call component.getAttributes().put(Map.Entry.getKey(),
>>> Map.Entry.getValue()).
>>>
>>> Attributes
>>>
>>> value an EL Expression that evaluates to a Map<String, Object>. The
>>> values may be String literals or ValueExpressions.
>>>
>>> SECTION: ADD f:passThroughAttribute
>>>
>>> Add a new tag in the jsf_core taglibrary for facelets (not JSP). Here's
>>> the spec.
>>>
>>> Add an attribute to the passThroughAttributes map of the UIComponent
>>> associated with the closest parent UIComponent.
>>>
>>> Attributes
>>>
>>> name The name of the passThrough attribute to be set.
>>>
>>> value The value of the passThrough attribute to be set. If the value is a
>>> ValueExpression, it must not be evaluated before storing in the map.
>>>
>>> SECTION: add f:passThroughAttributes
>>>
>>> Add a new tag in the jsf_core taglibrary for facelets (not JSP). Here's
>>> the spec.
>>>
>>> For each Map.Entry in the Map<String, Object> referenced by the value
>>> attribute of this tag, take the following action. Call
>>> component.getPassThroughAttributes().put(Map.Entry.getKey(),
>>> Map.Entry.getValue()).
>>>
>>> Attributes
>>>
>>> value The value of the passThrough attribute to be set. If the value is
>>> a ValueExpression, it must not be evaluated before storing in the map.
>>> The entries in this map are rendered as pass through attributes when the
>>> component is rendered. See ResponseWriter for how this happens.
>>>
>>> SECTION: NON-CHANGE
>>>
>>> While we all love how clever it feels to use namespaced attributes, I
>>> don't think it adds enough value. I'm not going to add it to the spec.
>>>
>>> SECTION: CHANGE ResponseWriter class javadocs.
>>>
>>> Add new section at the end of the existing class javadocs.
>>>
>>> Rendering Pass Through Attributes
>>>
>>> The set of attributes written for a component is determined by its
>>> Renderer. In addition to these "renderer specific" attributes, "pass
>>> through" attributes are also possible. Pass through attributes are
>>> contained in the Map returned by UIComponent.getPassThroughAttributes().
>>> If a UIComponent instance is passed to startElement(), the
>>> ResponseWriter must ensure that all pass through attributes on that
>>> component are rendered on the root markup element for that component.
>>> If there is a pass through attribute with the same name as a renderer
>>> specific attribute, the pass through attribute takes precedence. Pass
>>> through attributes are rendered with a call to writeURIAttribute().
>>>
>>> SECTION: CHANGE ResponseWriter.startElement() javadocs
>>>
>>> Add this text at the end of the existing text that describes the
>>> "component" parameter.
>>>
>>> This component is inspected for its pass through attributes as described
>>> in the class javadocs.
>>>
>>> SECTION: CHANGE VDLDocs and RenderKit docs
>>>
>>> Strike the term "pass through attribute" from the VDLDoc and RenderKit
>>> docs. In its place, use similar text that conveys the meaning without
>>> using the words "pass through"
>>>
>>> Ed
>>>
>>
>
>
>