Hi Ed, hi everyone,<br><br>as asked for by Ed, here is the outcome of several JSFdays discussions we had on the current state of the PFD:<br><br>- 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 &lt;composite:renderUsingPageChildren/&gt; - 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.<br>
<br>- 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 &quot;refresh&quot;-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&#39;t mean anything for the non-javascript case, and doesn&#39;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.<br>
<br>- 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&#39;t have done before) cause with partial-state it is not a problem to have this information in the component attributes map.<br>
<br>regards,<br><br>Martin<br><br><br clear="all"><br>-- <br><br><a href="http://www.irian.at">http://www.irian.at</a><br><br>Your JSF powerhouse - <br>JSF Consulting, Development and <br>Courses in English and German<br>
<br>Professional Support for Apache MyFaces<br>