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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
