"Craig R. McClanahan" wrote:
> The ApplicationConfig object itself is exposed (as a request attribute),
> so all the usual introspection-based access to its innards is still
> possible. What's missing?
I was trying to expose the innards in a very convenient way so that they
would be trivial to use with other presentation systems. For example,
with the ContextHelper, the <struts:errors/> tag could be rendered in a
Velocity template as
$!get.errorMarkup
and the Action for a form could be represented as
<form method="POST" action="$get.action('/logonSubmit')">
a forward as
<a href="$get.link('logon')">Sign in</a>
and so forth.
Gabriel and Geir used a slightly different approach in their
Velocity/Struts toolkit, that more closely mimics the tags, and so
renders the same thing as
$!html.errorMarkup()
<form method="POST" action="$html.actionMappingURL('/logonSubmit_vm')">
<a href="$html.link('logon_vm')">Sign in</a>
and they also have another object for $bean.message(), et cetera.
Can we do the equivalent with the ActionConfig object?
I'm now taking a look at the current JSTL EA to see what we would need
to
do to support that in a similar fashion, so we might put these together
into a common approach.
One thought might be to have ContextHelper factories that might render
an optimized API object for a given presentation device. Which would
also
imply that would could have a null factory that would not bother
inserting anything, if that is a concern.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
