[jsr-314-open] [Behavior] Why is HtmlOutputText not a ClientBehaviorHolder ?

Ed Burns Ed.Burns at Sun.COM
Tue Jan 12 15:59:31 EST 2010


>>>>> On Tue, 12 Jan 2010 21:15:04 +0100, Matthias Wessendorf <matzew at apache.org> said:

MW> On Tue, Jan 12, 2010 at 9:07 PM, Ed Burns <Ed.Burns at sun.com> wrote:
>>>>>>> On Tue, 12 Jan 2010 11:03:34 -0500, Andy Schwartz <andy.g.schwartz at gmail.com> said:
>> 
AS> So strange.  Matthias and Lincoln's responses didn't make it to my
AS> Oracle account, but did make it to gmail.  Apparently I've got some
AS> mail delivery issues here.  Yay.
>> 
AS> On Tue, Jan 12, 2010 at 10:45 AM, Lincoln Baxter, III
AS> <lincolnbaxter at gmail.com> wrote:
>>>> 
>>>> What are your performance concerns, if I have not inferred correctly?
>>>> 
>> 
AS> My concern is that there will be increased overhead during
AS> h:outputText rendering due to an increased # of attribute lookups  It
AS> is possible that overhead is nominal, but not sure.  The use case
AS> where this overhead would be most noticeable would be the stamping
AS> case, where we may end up stamping out h:outputText components many
AS> times (once per row/column of a data table).
>> 
>> I agree with Andy.  I oppose doing anything to h:outputText until we
>> have some concrete performance numbers on the impact of the proposed
>> change.  Also, I feel the benefit to the user of doing this change is
>> marginal at best.

MW> I totally understand that. For me (personal requirement) the Trinidad2
MW> <tr:outputText>
MW> is all I need and making a custom (or extensional) outputText
MW> ClientBehaviorHolder
MW> is pretty trivial :-)

MW> So, I think we can close the ticket as h:outputText was never having "DOM apis"
MW> and adding them could be worse for performance; Do you want me to close it ?

Yes please.

Ed




More information about the jsr-314-open-mirror mailing list