[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