jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "T. V. Raman" <tvra...@us.ibm.com>
Subject Re: [RDC] Reason for #{...} syntax support in the ExpandTag
Date Thu, 18 Aug 2005 13:27:11 GMT

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 <akolkar@us.ibm.com> writes:
    Rahul> Stu Robertson <srobertson@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


Mime
View raw message