Re: [jsr-314-open] Outcome of JSFDays discussions
Hey Martin -
Some comments on the other topics that you raised. (See the new
"JavaScript disabled support" thread for comments on that issue.)
Martin Marinschek wrote On 4/2/2009 3:24 AM ET:
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.
This makes sense to me... ADF Faces has a page template/declarative
component mechanism that is very similar to JSF 2.0 composite
components. We perform facet relocation in these components (not just
for rendering). If we are interested in pursuing this I might be able
to provide more details on the implementation strategy that we use.
BTW, when looking through the PFD spec (the pdf doc) for info on
<composite:renderUsingPageChildren>, I didn't find anything (just the
vdl/pdl doc) - though I did find a reference to
<composite:insertChildren> in section 10.3.3.3. So at one point was
<composite:renderUsingPageChildren> named <composite:insertChildren>?
"insertChildren" seems like a nicer name - and is consistent with our
<composite:insertFacet> tag name. Anyone remember how we ended up with
"renderUsingPageChildren"? Is "insertChildren" not an appropriate
name?
- 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.
Definitely a fan of anything that we can do to improve ease of
debugging. Regarding full vs partial state saving... I am thinking
that we may need to save full state in certain cases (eg. if we run into
cases that partial state saving cannot handle correctly). If we are
concerned about bloating the saved state size with location information
in such cases, one option might be to only store location information
when project stage == development. Actually, perhaps only storing
location information during the development (or, at least,
non-production) stage might not be a bad idea anyway?
Andy