9:45 a.m.
Got it. I had guessed panelgroup would fill that role, but I didn't want to
influence the answer ;)
I don't see this as a gap if panelgroup implements clientbehaviorholder, but
for convenience, and consistency, I'd argue we should add this to
h:outputtext.
If performance is a concern (say, because of inline text being wrapped into
output text components on view construction), then the jsf impl should be
free to use a lightweight impl-specific component instead.
What are your performance concerns, if I have not inferred correctly?
Lincoln Baxter III
http://ocpsoft.com
http://scrumshark.com
Keep it simple.
On Jan 12, 2010 10:21 AM, "Matthias Wessendorf" <matzew(a)apache.org>
wrote:
On Tue, Jan 12, 2010 at 4:02 PM, Andy Schwartz <andy.schwartz(a)oracle.com>
wrote: > Hey Lincoln - > >...
I think that using h:panelGrid is not perfect, but it is better than
abusing <label>.
-Matthias
> Andy > >> >> The next question is: Do we need
such a mechanism? That's,
for the most >> part, t...
-- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/sessions:
http://www.slidesh...
10:02 a.m.
New subject: [jsr-314-open] [Behavior] Why is HtmlOutputText not a ClientBehaviorHolder ?
On Tue, Jan 12, 2010 at 4:45 PM, Lincoln Baxter, III
<lincolnbaxter(a)gmail.com> wrote:
Got it. I had guessed panelgroup would fill that role, but I
didn't want to
influence the answer ;)
I don't see this as a gap if panelgroup implements clientbehaviorholder, but
for convenience, and consistency, I'd argue we should add this to
h:outputtext.
If performance is a concern (say, because of inline text being wrapped into
output text components on view construction), then the jsf impl should be
free to use a lightweight impl-specific component instead.
in my case (trinidad) I don't worry at all, as the <tr:outputText> is
all I need; I was just "worried" about vanilla JSF
-Matthias
What are your performance concerns, if I have not inferred correctly?
Lincoln Baxter III
http://ocpsoft.com
http://scrumshark.com
Keep it simple.
On Jan 12, 2010 10:21 AM, "Matthias Wessendorf" <matzew(a)apache.org>
wrote:
On Tue, Jan 12, 2010 at 4:02 PM, Andy Schwartz <andy.schwartz(a)oracle.com>
wrote: > Hey Lincoln - > >...
I think that using h:panelGrid is not perfect, but it is better than
abusing <label>.
-Matthias
> > Andy > >> >> The next question is: Do we need such a mechanism?
That's,
> > for the most >> part, t...
-- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slidesh...
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10:03 a.m.
New subject: [jsr-314-open] [Behavior] Why is HtmlOutputText not a ClientBehaviorHolder ?
So strange. Matthias and Lincoln's responses didn't make it to my
Oracle account, but did make it to gmail. Apparently I've got some
mail delivery issues here. Yay.
On Tue, Jan 12, 2010 at 10:45 AM, Lincoln Baxter, III
<lincolnbaxter(a)gmail.com> wrote:
What are your performance concerns, if I have not inferred correctly?
My concern is that there will be increased overhead during
h:outputText rendering due to an increased # of attribute lookups. It
is possible that overhead is nominal, but not sure. The use case
where this overhead would be most noticeable would be the stamping
case, where we may end up stamping out h:outputText components many
times (once per row/column of a data table).
Andy
10:09 a.m.
New subject: [jsr-314-open] [Behavior] Why is HtmlOutputText not a ClientBehaviorHolder ?
On Tue, Jan 12, 2010 at 5:03 PM, Andy Schwartz
<andy.g.schwartz(a)gmail.com> wrote:
So strange. Matthias and Lincoln's responses didn't make it
to my
Oracle account, but did make it to gmail.
I noticed some IMAP issue there. So I see you on IM :-)
Apparently I've got some
mail delivery issues here. Yay.
On Tue, Jan 12, 2010 at 10:45 AM, Lincoln Baxter, III
<lincolnbaxter(a)gmail.com> wrote:
>
> What are your performance concerns, if I have not inferred correctly?
>
My concern is that there will be increased overhead during
h:outputText rendering due to an increased # of attribute lookups. It
is possible that overhead is nominal, but not sure. The use case
where this overhead would be most noticeable would be the stamping
case, where we may end up stamping out h:outputText components many
times (once per row/column of a data table).
Andy
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
5255
days inactive
5255
days old
jsr-314-open-mirror@lists.jboss.org
3 comments
3 participants
participants (3)
-
Andy Schwartz -
Lincoln Baxter, III -
Matthias Wessendorf