Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Discussion" <users@myfaces.apache.org>
Received-SPF: pass (nike.apache.org: domain of awiner@gmail.com designates
 209.85.198.188 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=LnhLOfjR6JbxJzimX6Vtrn/9WDlPrYoOgw+sFkKWviwJnlCNOhCiTgBxRb+P2jREgTK05RAIdiTh9Aw3xu5XVlgpHcgmaiSRIzcmY8X6iZJDJ3/hx7Wa/Lez+2vvtr603OqBF9AKcKZKrO9pCwaBkNqr4pnRAJ5TxM9aEKhDZo4=
Message-ID: <6dac79b90709040829x535f008fy463402e120f5f6a7@mail.gmail.com>
Date: Tue, 4 Sep 2007 08:29:58 -0700
From: "Adam Winer" <awiner@gmail.com>
To: "MyFaces Discussion" <users@myfaces.apache.org>
Subject: Re: trinidad outputFormat and f:param support
In-Reply-To: <5bbf92e70709040554r134b5f6sdd91c77430e273f6@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <12385896.post@talk.nabble.com>
	 <5bbf92e70708291210s25ef941od28ac6ac77d6bbc@mail.gmail.com>
	 <bc36a6210708291228o2494a153o486a4a1c36f836a@mail.gmail.com>
	 <12401317.post@talk.nabble.com>
	 <bc36a6210708300817n7c9b947fi4d8cf4042b0a6e97@mail.gmail.com>
	 <6dac79b90709032225s6bc47750xc6eb4306fbaeae73@mail.gmail.com>
	 <5bbf92e70709040554r134b5f6sdd91c77430e273f6@mail.gmail.com>

-0.5;  outputText performance is really critical to overall performance,
and even adding a boolean attribute slows it down a bit.

-- Adam


On 9/4/07, Danny Robinson <dannyjrobinson@gmail.com> wrote:
> Should we look at providing this variable replacement functionality into
> outputText.  Although I'm against just parsing the text by default, as this
> would just add unnecessary parsing in 99% of the cases.  Should we instead
> look at an extra attribute that forces parsing of the string for variable
> substitution.
>
> Danny
>
> On 9/4/07, Adam Winer <awiner@gmail.com> wrote:
> > BTW, for all of these examples, you should just use tr:outputText
> > instead of tr:outputFormatted.
> >
> > outputFormatted really has nothing to do with "outputFormat".
> > What tr:outputFormatted gives you is support for (a subset of)
> > HTML formatting without opening the security hole of
> > escape="false".
> >
> > -- Adam
> >
> >
> >
> > On 8/30/07, Andrew Robinson <andrew.rw.robinson@gmail.com > wrote:
> > > Well you could do:
> > >
> > > <tr:outputFormatted value="#{myfunc:format2(str, arg1, arg2)}" />
> > >
> > > where you could write format1, format2, etc. EL functions to do the
> work.
> > >
> > > You could also do:
> > >
> > > <t:buffer into="#{formattedString}">
> > > <h:outputFormat value="#{message.key}">
> > >   <f:param value="param1" />
> > > </h:outputFormat>
> > > </t:buffer>
> > >
> > > <tr:outputFormatted value="#{formattedString}" />
> > >
> > > On 8/30/07, Paul Mander < paul.mander@chordiant.com> wrote:
> > > >
> > > >
> > > >
> > > > Andrew Robinson-5 wrote:
> > > > >
> > > > > Well, that is not localizable
> > > > >
> > > > > I think the use case that he means is more like:
> > > > >
> > > > > <tr:outputFormatted value="#{messages.str}">
> > > > > <f:param value="#{myarg}" />
> > > > > </tr:outputFormatted>
> > > > >
> > > > > messages.properties
> > > > > str = Test {0} param
> > > > >
> > > > >
> > > >
> > > > That's a better example.
> > > >
> > > > --
> > > > View this message in context:
> http://www.nabble.com/trinidad-outputFormat-and-f%3Aparam-support-tf4347417.html#a12401317
> > > > Sent from the MyFaces - Users mailing list archive at Nabble.com.
> > > >
> > > >
> > >
> >
>
>
>
> --
> Chordiant Software Inc.
> www.chordiant.com