jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul P Akolkar <akol...@us.ibm.com>
Subject Re: [RDC] Reason for #{...} syntax support in the ExpandTag
Date Thu, 18 Aug 2005 07:55:29 GMT
Stu Robertson <srobertson@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?

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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message