dev@javaserverfaces.java.net

Re: using jsfc= with outputText?

From: Keith Zantow <kzantow_at_gmail.com>
Date: Fri, 14 Jul 2006 16:35:13 -0400

I think that would be the easiest option. It seems to me that the most
common use case for this is HTML designers who need some filler text
to see what a page will look like.

The default jsfc behavior is to replace a tag with the corresponding
component, so ui:replace seems redundant, ui:output makes the most
sense but doesn't indicate that anything will be replaced by it's
name, ui:text is shorter. :)

<span jsfc="ui:text" value="#{...}">
Filler text...
</span>

It feels to me like duplicating h:outputText a bit (even though
h:outputText is somewhat pointless with Facelets, anyway).

Similar to what you suggested there could be a 'jsfr' approach where
an attribute indicates to "pass through" the HTML tag and replace the
child element:

<div style="color: red;" jsfc-replace-child="h:outputText" value="#{...}">
Filler text...
</div>

is essentially:

<div style="color: red;">
<h:outputText value="#{...} />
</div>

I can see problems with attribute conflicts here.

I think the ui:replace/ui:output/ui:text is probably the best option.

-Keith



On 7/14/06, jacob_at_hookom.net <jacob_at_hookom.net> wrote:
> yeah, I thought about that too, much like ui:repeat passes through everything and decorates some behavior, do the same for a ui:output.
>
> >What about instead, a ui:replace tag?
> >
> ><span jsfc="ui:replace" value="#{blah}">
> >Text here will be replaced by the blah value...
> ></span>
> >
> >-Keith
> >
> >
> >
> >On 7/14/06, jacob_at_hookom.net <jacob_at_hookom.net> wrote:
> >> what about a "jsfr" which is for replace?
> >>
> >> >It's my understanding that any tag with jsfc is replaced in total with
> >> >the jsf component on rendering. Yeah, the div should probably remain
> >> >and maybe another div or span should be put inside it with the jsfc
> >> >attributes on it.
> >> >
> >> >On 7/14/06, Keith Zantow <kzantow_at_gmail.com> wrote:
> >> >> In your example, the <div would be replaced with text, right? I think
> >> >> that would cause confusion when it is rendered and the text isn't the
> >> >> same as the template with the div in it.
> >> >>
> >> >> Perhaps I'm confused about how the jsfc attribute works (or the
> >> >> outputText component). If the <div and all attributes are retained as
> >> >> part of the output with the value attribute as the inner text and the
> >> >> "Sample Text" removed, it seems that could be quite useful...
> >> >>
> >> >> -Keith
> >> >>
> >> >>
> >> >>
> >> >> On 7/14/06, Mike Kienenberger <mkienenb_at_gmail.com> wrote:
> >> >> > On 7/14/06, Nikita Tovstoles <nikita_at_doppelganger.com> wrote:
> >> >> > > >I'm wondering
> >> >> > > >whether it's possible to use jsfc to somehow replace hard-coded
> >output
> >> >> > > >with h:outputText:
> >> >> > > >
> >> >> > > >web designer produces:
> >> >> > > >
> >> >> > > ><div align="right" class="errorText">
> >> >> > > >Sample Text
> >> >> > > ></div>
> >> >> >
> >> >> > On 7/14/06, jacob_at_hookom.net <jacob_at_hookom.net> wrote:
> >> >> > > I'm just wondering if the Renderer for h:outputText should avoid
> >> >rendering its children when a value is defined.
> >> >> >
> >> >> > Right, because otherwise, you could do something like this. (Right
> >> >> > now, you'd still get the sample text, yes?)
> >> >> >
> >> >> > <div align="right" class="errorText" jsfc="h:outputText">
> >> >> > Sample Text
> >> >> > </div>
> >> >> >
> >> >> > Maybe a jsfc-ignore-children="true" flag?
> >> >> >
> >> >> > ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> >> >> > For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
> >> >> >
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> >> >> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
> >> >>
> >> >>
> >> >
> >> >---------------------------------------------------------------------
> >> >To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> >> >For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> >> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> >For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
>