[jsr-314-open] required attributes in composite components

[Andy Schwartz]

I was going to +1 - I like Kito's idea of using a component 
author-specified attribute, and I also like Dan's idea of a more generic 
"strict" attribute - though then it occurred to me that the arbitrary 
attribute behavior isn't just a feature of Facelets compositions - but 
this is also the way that Facelets works for any old (Java-based) Faces 
component.  That is, I believe that:

  <h:commandButton foo="bar">

Just ends up stashing the "foo" attribute value in the 
<h:commandButton>'s attribute map. (Or, at least, I think that's what 
happens.)  So now I am wondering whether there is merit in keeping 
behavior consistent between composite and non-composite components in 
this regard.  Would it be confusing that arbitrary attributes are pushed 
into the attribute map for some types of components, but not for 
others?  Hmm... maybe the benefits of providing quick feedback in cases 
where the attribute is known to be invalid (ie. in the composite 
component "strict" case) outweigh the drawbacks of the inconsistency?

If we do go forward with a strict capability for composite components, 
do we want to check/enforce this in all project stages?  Seems like we 
might be able to get away with only performing the strict checks in the 
development project stage (sort of like disabling assertions for 
production releases).

Andy

Dan Allen wrote On 4/2/2009 2:34 PM ET:
> Makes sense to me. One of the things I have always been uneasy about 
> with Facelets is the amorphous aspect of the tags. So when it comes to 
> defining a real component, I think we absolutely want the component 
> author to be able to decide whether to make the tag strict or not.
>
> Would a more generic attribute like strict="true" make more sense just 
> in case we want to enforce other restrictions?
>
> -Dan
>
> On Thu, Apr 2, 2009 at 7:56 AM, Kito Mann <kito.mann at virtua.com 
> <mailto:kito.mann at virtua.com>> wrote:
>
>     So, here's one other thing that came up at JSFDays -- the fact
>     that composite components (like Facelet compositions) don't
>     restrict which attributes can be used. This is fine for Facelet
>     compositions, but since composite components can define specific
>     attributes, it makes sense to give component authors the ability
>     to restrict page authors to those attributes.
>
>     I think the easiest way to handle this from a component author's
>     perspective would be to add an attribute to the
>     <component:interface> tag:
>
>     <component:interface restrictAttributes="true">
>       <component:attribute name="name" required="true"/>
>       <component:attribute name="size"/>
>     </component:interface>
>
>     So, in this case, this component would _only_ accept the name and
>     size attributes, and the runtime would throw an exception if
>     another attribute were used. An IDE could also complain when
>     someone tried to use a different attribute.
>
>     Thoughts?
>     ---
>     Kito D. Mann -- Author, JavaServer Faces in Action
>     http://twitter.com/kito99  http://twitter.com/jsfcentral
>     http://www.virtua.com - JSF/Java EE consulting, training, and
>     mentoring
>     http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
>     +1 203-404-4848 x3
>
>     Public JSF Course in NYC (April 21st-24th):
>     http://www.regonline.com/jsf-course
>
>
>
>
> -- 
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
>
> NOTE: While I make a strong effort to keep up with my email on a daily
> basis, personal or other work matters can sometimes keep me away
> from my email. If you contact me, but don't hear back for more than a 
> week,
> it is very likely that I am excessively backlogged or the message was
> caught in the spam filters.  Please don't hesitate to resend a message if
> you feel that it did not reach my attention.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090402/8f567091/attachment.html