[jsr-314-open] #{compositeComponent.attrs....}
by David Geary
Is it possible to dispense with having to type "#compositeComponent.attrs."
in the implementation sections of composite components? It's cumbersome.
Besides, Facelets custom tags let you access attribute values with their
simple names, for example you could use a Facelets tag like this:
<mytags:planet name="mercury" image="#{resource['images:Mercury.gif']}"/>
and in the implementation of the planet tag, you can do this:
<h:graphicImage style="border: none"
value="#{image}"/>
With a JSF composite component, you have to do
..value="#{compositeComponent.attrs.image}". Maybe I'm missing something,
but it doesn't seem to be too much of a technical feat to remove the need to
type compositeComponent.attrs (a variable resolver that searches
compositeComponents.attrs, as necessary?)
It seems weird that we're taking a step backwards in this respect, even as
we move forward from Facelets tags to more feature-rich composite
components.
david
15 years
Re: [jsr-314-open] Outcome of JSFDays discussions
by Ed Burns
>>>>> On Thu, 02 Apr 2009 09:24:59 +0200, Martin Marinschek <mmarinschek(a)APACHE.ORG> said:
MM> - A very small thing, but could be very useful: we could define that
MM> the component-tag-handler of the facelets-vdl needs to put the
MM> location of the component into the component-attributes map. With
MM> this, we can emit the location of the component if there is an
MM> exception during any lifecyle-phase - I believe this would help many
MM> application developers. We can do this now (and shouldn't have done
MM> before) cause with partial-state it is not a problem to have this
MM> information in the component attributes map.
Done.
15 years
[jsr-314-open] Outcome of JSFDays discussions
by Martin Marinschek
Hi Ed, hi everyone,
as asked for by Ed, here is the outcome of several JSFdays discussions we
had on the current state of the PFD:
- Kito did some demos which showed that we would really need something like
ui:define/ui:insert for composite components. Currently, the only way to
include children is saying <composite:renderUsingPageChildren/> - but we
don`t want the children to be there only for the rendering, but for all
lifecycle-phases. Same for facets - if we have the possibility to include
facets at defined locations in the composite component (not only rendering
them), we add a lot of flexibility for composite component authors;
flexibility they had before with the ui:define/ui:insert combination, but
even more integrated into the plain JSF component idea by using facets
instead of ui:defines.
- In the presentation about JSF 2.0 features, there was a question from the
audience what happens with AJAX support when JavaScript is disabled. While
we said we wouldn´t directly support degradation for the non-javascript
case, I do think we should make it possible for the implementation to do so.
What we do in cs-JSF for supporting things like this is we automatically
render a "refresh"-button for each input-component which triggers a submit
of the page when javascript is disabled. However, the current API of
ClientSideBehaviour is not useful for this - getScript() doesn't mean
anything for the non-javascript case, and doesn't allow to render something
else than a script to the markup. So, Andy, please forgive me that I am
bugging you again with renaming things in the behaviour-feature, but can we
- instead of having getScript() - have beforeEncodeBegin() and
afterEncodeEnd() callbacks (potentially also afterEncodeBegin() and
beforeEncodeEnd()). Then the behaviour itself could decide what to render,
can be a script, can be something else when javascript is disabled. Does
this make sense to you? If I get to have another wish, the
ClientSideBehaviour should then be renamed (sorry again!) to
RendererBehaviour.
- A very small thing, but could be very useful: we could define that the
component-tag-handler of the facelets-vdl needs to put the location of the
component into the component-attributes map. With this, we can emit the
location of the component if there is an exception during any lifecyle-phase
- I believe this would help many application developers. We can do this now
(and shouldn't have done before) cause with partial-state it is not a
problem to have this information in the component attributes map.
regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
15 years
Re: [jsr-314-open] Groovy support
by Ed Burns
>>>>> On Wed, 18 Mar 2009 04:07:08 -0400, Kito Mann <kito.mann(a)VIRTUA.COM> said:
KM> So, after perusing the spec, I noticed that there's no mention
KM> specifically of Groovy. And I don't see much on the Groovy site
KM> itself indicating when/if the Groovy JSR will ever be finished. Any
KM> insight?
Right, as you know, at nearly every JSF 2 talk I give, I implore the
audience to pepper Mr. La Forge with annoying emails about completing
the JSR. Until it is completed, we can't explicitly mention Groovy.
The spec language we currently have is as specific as I can get.
Do you have another suggestion?
Ed
15 years
Re: [jsr-314-open] organizing composite component templates
by Ed Burns
>>>>> On Fri, 10 Apr 2009 15:21:42 -0400, Dan Allen <dan.j.allen(a)GMAIL.COM> said:
DA> Another question came up at the JSF 2.0 presentation last night, this one
DA> about composite components.
DA> Can composite component namespaces/directories have multiple nested
DA> directories? Same question with resource locations?
DA> http://java.sun.com/jsf/composite/storefront/form/
The way we agreed to do this was the following syntax in a
facelet-taglibraryA.xml file:
<facelet-taglib>
<namespace>http://domain.com/path</namespace>
<composite-library-name>compositeTest</composite-library-name>
</facelet-taglib>
And this in a facelet-taglibraryB.xml file
<facelet-taglib>
<namespace>http://domain.com/path/nested</namespace>
<composite-library-name>compositeTestNested</composite-library-name>
</facelet-taglib>
Yes, you are correct that the resource naming scheme prevents nested
resource libraries. Nested resource libraries were not on the list of
requirements when we designed this feature back in November of 2007. We
will not accept this requirement change at this point.
Ed
15 years
[jsr-314-open] minor feature enhancement for Facelets/VDL
by Dan Allen
I just thought of a feature I have often needed in Facelets that perhaps we
can weave into the VDL. It would be nice to know if a named template has
been defined inside the master template. Consider the following example:
page.xhtml
<ui:composition template="/WEB-INF/template.xhtml" ...>
<ui:param name="title" value="VDL Template Page"/>
<ui:define name="content">
<h:outputText value="Hello World" />
</ui:define>
</ui:composition>
template.xhtml
<html ...>
<h:head>
<title>#{not empty title ? title : 'My Site'}</title>
</h:head>
<body>
<div id="container">
<ui:insert name="content"/> <- how do I know if it has been
defined?
</div>
</body>
</html>
Since the <ui:param> creates a regular variable, I can check whether it is
empty or not. But I do not have a way to check if the named template
"content" has been defined. Of course, I can nest default content within the
<ui:insert>, which is used when the named template is not defined, but there
are cases when I simply need to know whether or not it is defined. Could we
come up with some way to check if it is defined?
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
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.
15 years
Re: [jsr-314-open] Groovy support
by Ed Burns
>>>>> On Mon, 13 Apr 2009 13:45:30 -0400, Kito Mann <kito.mann(a)VIRTUA.COM> said:
KM> On Fri, Mar 20, 2009 at 5:05 PM, Kito Mann <kito.mann(a)virtua.com> wrote:
>> That's what I was afraid of :-). What about automatically reloading
>> configuration -- did I miss that in the spec?
KM> Anyone have an answer for this one?
Container vendors would rather have this un-specified so it can be a
value-added feature.
Ed
15 years
Re: [jsr-314-open] @CustomScoped value attribute
by Ed Burns
>>>>> On Fri, 10 Apr 2009 12:28:12 -0600, David Geary <clarity.training(a)GMAIL.COM> said:
DG> The javadocs for @CustomScoped indicate that the value of the value
DG> attribute must evaluate to a String:
DG> When this annotation, along with ManagedBean is found on a class, the
DG> runtime must act as if a <managed-bean-scope<VALUE<managed-bean-scope>
DG> element was declared for the corresponding managed bean, where VALUE is the
DG> value of the value() attribute, which must be an EL expression that
DG> evaluates to a String.
DG> I thought it was supposed to evaluate to a map.
Fixed.
15 years
[jsr-314-open] required attributes in composite components
by Kito Mann
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
15 years
[jsr-314-open] organizing composite component templates
by Dan Allen
Another question came up at the JSF 2.0 presentation last night, this one
about composite components.
Can composite component namespaces/directories have multiple nested
directories? Same question with resource locations?
http://java.sun.com/jsf/composite/storefront/form/
According to section 10.3.3.1 -
If the substring following “http://java.sun.com/jsf/composite/” contains
a “/” character, or any characters not legal for a library name the
following action must be taken....<log error>
From the quote above it seems this is not possible, so everything will end
up in one directory - could be sloppy. Better would be to allow this nesting
to occur:
e.g., /resources/storefront/form/creditCard.xhtml
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
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.
15 years