Ted,

Thanks for responding.

>>I think we'd all be happy to see better support for Velocity, and other
templating mechanisms. Geir did some work along these lines last spring.<<

I've seen this work, and we're having related conversations on velocity-user
now.

>>Forwarding and redirecting is how HTTP generally works,
so that became the default approach.<<

For precision, redirecting is an HTTP capability. Forwarding is specific to
server-side web technologies like servlets.

>>Agreed. Oleg's been working on a service manger to help offset this.<<

Like I said, I've looked at this. Perhaps it's not very far along, but it
wasn't exactly what I was thinking of. For one thing, I don't see a need for
it to be based on reflection/introspection. The concept of "services" is
along the lines of what I envision; but how to specify them and how and
where they are called is different. As I've thought about it more, I see the
ActionServlet becoming a coordinator of the services and their configuration
but getting away from doing a lot of the "real" work.

>>An ActionForward sub-class can be specified in the ActionServlet config,
along with the default ActionMapping class, form bean class, and
multipart handler.<<

I've seen that, but since the ActionServlet acts on the mapping instances
rather than asking the mapping instances to operate on themselves, the
flexibility to use custom mapping classes only goes so far.

>>Cedric has done some interesting work in the tiles library, where the
view is rendered from a runtime configuration rather than a physical
file. Perhaps a variation of this approach would also work for a non-JSP
templating mechanism.<<

I see the view rendering piece as one of the services which the
ActionServlet would coordinate. The default would work as it does now, that
is it would forward/redirect as specified by the ActionForward. A
velocity-supporting service could build the context and merge with the
template to complete the request (no forwarding/redirecting required). The
name "ActionForward" has implications w.r.t. forwarding/including, so that
may need addressed.

>>The number of settings used by an ActionServlet has grown a bit, and it
does seem like time to collect these into a coherent binder object, like
a StrutsContext. This could then be passed to the view via the request,
and any access via the application context deprecated.<<

Agreed. If it's just one thing passed in the request, would that provide
access to the session and servlet contexts as well? If that's what you were
thinking, it sounds good.

>>I think most of the tag extensions are destined for Taglibs, depending
on how JSPTL shakes out, which would include the bean tags and the
MessageResource support. They already have an i18n tag modelled that
works in the same way.<<

That aounds great, as long as I don't have to use tags to interact with
MessageResources.

>>I'd love to more the generic connection pool to the Commons, if someone
wanted to maintain it. Or maybe we could adopt Excalibur's instead.
Binding the datasource to the servlet context is problematic in a
layered architecture, and IMHO, sending developers the wrong message.<<

I agree about the datasources and the servlet context.

Thanks again for the response,

Donnie


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to