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]>
