[jsr-314-open] Outcome of JSFDays discussions

[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090402/70e4b97d/attachment.html