[jsr-314-open] Outcome of JSFDays discussions
Martin Marinschek
mmarinschek at APACHE.ORG
Tue Apr 7 08:54:29 EDT 2009
On 4/3/09, Andy Schwartz <andy.schwartz at oracle.com> wrote:
> Hey Martin -
> 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?
I am absolutely for insertChildren and insertFacets, and relocation!
Ed, do you think we could do this change?
>
>> - 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?
a very reasonable idea!
regards,
Martin
More information about the jsr-314-open-mirror
mailing list