<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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:<br>
<br>
<h:commandButton foo="bar"><br>
<br>
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?<br>
<br>
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).<br>
<br>
Andy<br>
<br>
Dan Allen wrote On 4/2/2009 2:34 PM ET:
<blockquote
cite="mid:19758da0904021134t41877c42x2e5c63773f97cf6e@mail.gmail.com"
type="cite">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.<br>
<br>
Would a more generic attribute like strict="true" make more sense just
in case we want to enforce other restrictions?<br>
<br>
-Dan<br>
<br>
<div class="gmail_quote">On Thu, Apr 2, 2009 at 7:56 AM, Kito Mann <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:kito.mann@virtua.com">kito.mann@virtua.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<br>
<br>
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:<br>
<br>
<component:interface restrictAttributes="true"><br>
<component:attribute name="name" required="true"/><br>
<component:attribute name="size"/><br>
</component:interface><br>
<br>
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.<br>
<br>
Thoughts?<br clear="all">
---<br>
Kito D. Mann -- Author, JavaServer Faces in Action<br>
<a moz-do-not-send="true" href="http://twitter.com/kito99"
target="_blank">http://twitter.com/kito99</a> <a
moz-do-not-send="true" href="http://twitter.com/jsfcentral"
target="_blank">http://twitter.com/jsfcentral</a><br>
<a moz-do-not-send="true" href="http://www.virtua.com"
target="_blank">http://www.virtua.com</a> - JSF/Java EE consulting,
training, and mentoring<br>
<a moz-do-not-send="true" href="http://www.JSFCentral.com"
target="_blank">http://www.JSFCentral.com</a> - JavaServer Faces FAQ,
news, and info<br>
+1 203-404-4848 x3<br>
<br>
Public JSF Course in NYC (April 21st-24th): <a moz-do-not-send="true"
href="http://www.regonline.com/jsf-course" target="_blank">http://www.regonline.com/jsf-course</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Dan Allen<br>
Senior Software Engineer, Red Hat | Author of Seam in Action<br>
<br>
<a moz-do-not-send="true" href="http://mojavelinux.com">http://mojavelinux.com</a><br>
<a moz-do-not-send="true" href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br>
<br>
NOTE: While I make a strong effort to keep up with my email on a daily<br>
basis, personal or other work matters can sometimes keep me away<br>
from my email. If you contact me, but don't hear back for more than a
week,<br>
it is very likely that I am excessively backlogged or the message was<br>
caught in the spam filters. Please don't hesitate to resend a message
if<br>
you feel that it did not reach my attention.<br>
</blockquote>
<br>
</body>
</html>