You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by Stu Robertson <sr...@nvisia.com> on 2005/08/18 06:27:26 UTC
[RDC] Reason for #{...} syntax support in the ExpandTag
Hi,
Just reading through the source code I noticed that the ExpandTag
accepts bodyContent with #{...} syntax, converts it to ${..} format,
and then applies the EL interpreter to it. I haven't noticed this in
the docs, and am just curious why the delayed execution is there. Is
it so that even cached, otherwise non-dynamic config file contents
can be made dynamic when the expand tag is rendered?
Thanks,
Stu
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: [RDC] Reason for #{...} syntax support in the ExpandTag
Posted by "T. V. Raman" <tv...@us.ibm.com>.
More importantly, you want those EL expressions evaluated at the
point where they are needed, rather than at page/config load
time.
So the simple example that uses a prompt of the form
<prompt>Hello ${model.user}</prompt>
if placed in a config file would end up getting compiled down to
a prompt
<prompt>Hello ""</prompt> since at the time that that expr gets
compiled, the user has not provided the prompt yet.
The delayed evaluation in
<prompt>hello #{model.user}</prompt>
allows the value populated in the model by a previous dialog
getting spliced into the prompt, which is what you want.
>>>>> "Rahul" == Rahul P Akolkar <ak...@us.ibm.com> writes:
Rahul> Stu Robertson <sr...@nvisia.com> wrote on
Rahul> 08/18/2005 12:27:26 AM:
>> Hi,
>>
>> Just reading through the source code I noticed that the
>> ExpandTag accepts bodyContent with #{...} syntax, converts
>> it to ${..} format, and then applies the EL interpreter to
>> it. I haven't noticed this in the docs, and am just
>> curious why the delayed execution is there. Is it so that
>> even cached, otherwise non-dynamic config file contents
>> can be made dynamic when the expand tag is rendered?
Rahul> <snip/>
Rahul>
Rahul> More or less, the expressions do not need to evaluated
Rahul> until certain conditions are met -- i.e. you've
Rahul> reached a particular state in a component or a
Rahul> particular rule within a group's config has been
Rahul> fired. It is also worth noting that the reason the
Rahul> configs exist as separate files is a facet of this RDC
Rahul> implementation, and the configs could well reside
Rahul> within the JSP if someone wants to scratch an itch, in
Rahul> which case, having two notations becomes mostly
Rahul> inevitable.
Rahul>
Rahul> For completion, this is analogous to the EL 2.1 spec
Rahul> draft Section 1.2.4 (component of the JSP 2.1 spec
Rahul> draft):
Rahul>
Rahul> <quote>While ${} and #{} eval-expressions are parsed
Rahul> and evaluated in exactly the same way by the EL, the
Rahul> underlying technology is free to impose restrictions
Rahul> on which syntax can be used according to where the
Rahul> expression appears.</quote>
Rahul>
Rahul> As you note above, the RDC framework uses the #{}
Rahul> notation in the config files (component or group) to
Rahul> stress that those expressions use delayed / deferred
Rahul> evaluation.
Rahul>
Rahul> -Rahul
--
Best Regards,
--raman
------------------------------------------------------------
T. V. Raman: PhD (Cornell University)
IBM Research: Human Language Technologies
Architect: RDC --- Conversational And Multimodal WWW Standards
Phone: 1 (408) 927 2608 T-Line 457-2608
Fax: 1 (408) 927 3012 Cell: 1 650 799 5724
Email: tvraman@us.ibm.com
WWW: http://almaden.ibm.com/u/tvraman (google:tv raman
AIM: emacspeak
GPG: http://www.almaden.ibm.com/cs/people/tvraman/raman-almaden.asc
Snail: IBM Almaden Research Center,
650 Harry Road
San Jose 95120
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: [RDC] Reason for #{...} syntax support in the ExpandTag
Posted by Stu Robertson <sr...@nvisia.com>.
Thanks for the insight Rahul. And thanks for resolving both of the
bugs I entered! The JSP forwarding issue definitely had me beat -
though it makes sense now. The forwarding does in fact clear the
buffer at the time of forwarding, but must continue rendering after
the forward returns.
Regards,
Stu
On Aug 18, 2005, at 2:55 AM, Rahul P Akolkar wrote:
> Stu Robertson <sr...@nvisia.com> wrote on 08/18/2005 12:27:26 AM:
>
>> Hi,
>>
>> Just reading through the source code I noticed that the ExpandTag
>> accepts bodyContent with #{...} syntax, converts it to ${..} format,
>> and then applies the EL interpreter to it. I haven't noticed this in
>> the docs, and am just curious why the delayed execution is there. Is
>> it so that even cached, otherwise non-dynamic config file contents
>> can be made dynamic when the expand tag is rendered?
>>
> <snip/>
>
> More or less, the expressions do not need to evaluated until certain
> conditions are met -- i.e. you've reached a particular state in a
> component or a particular rule within a group's config has been
> fired. It
> is also worth noting that the reason the configs exist as separate
> files
> is a facet of this RDC implementation, and the configs could well
> reside
> within the JSP if someone wants to scratch an itch, in which case,
> having
> two notations becomes mostly inevitable.
>
> For completion, this is analogous to the EL 2.1 spec draft Section
> 1.2.4
> (component of the JSP 2.1 spec draft):
>
> <quote>While ${} and #{} eval-expressions are parsed and evaluated in
> exactly the same way by the EL, the underlying technology is free to
> impose restrictions on which syntax can be used according to where the
> expression appears.</quote>
>
> As you note above, the RDC framework uses the #{} notation in the
> config
> files (component or group) to stress that those expressions use
> delayed /
> deferred evaluation.
>
> -Rahul
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: [RDC] Reason for #{...} syntax support in the ExpandTag
Posted by Rahul P Akolkar <ak...@us.ibm.com>.
Stu Robertson <sr...@nvisia.com> wrote on 08/18/2005 12:27:26 AM:
> Hi,
>
> Just reading through the source code I noticed that the ExpandTag
> accepts bodyContent with #{...} syntax, converts it to ${..} format,
> and then applies the EL interpreter to it. I haven't noticed this in
> the docs, and am just curious why the delayed execution is there. Is
> it so that even cached, otherwise non-dynamic config file contents
> can be made dynamic when the expand tag is rendered?
<snip/>
More or less, the expressions do not need to evaluated until certain
conditions are met -- i.e. you've reached a particular state in a
component or a particular rule within a group's config has been fired. It
is also worth noting that the reason the configs exist as separate files
is a facet of this RDC implementation, and the configs could well reside
within the JSP if someone wants to scratch an itch, in which case, having
two notations becomes mostly inevitable.
For completion, this is analogous to the EL 2.1 spec draft Section 1.2.4
(component of the JSP 2.1 spec draft):
<quote>While ${} and #{} eval-expressions are parsed and evaluated in
exactly the same way by the EL, the underlying technology is free to
impose restrictions on which syntax can be used according to where the
expression appears.</quote>
As you note above, the RDC framework uses the #{} notation in the config
files (component or group) to stress that those expressions use delayed /
deferred evaluation.
-Rahul