See intermixed. On Fri, 23 Nov 2001, Donnie Hale wrote:
> Date: Fri, 23 Nov 2001 11:25:15 -0500 > From: Donnie Hale <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: Struts Developers List <[EMAIL PROTECTED]> > Subject: RE: Struts extensibility, multiple servlets, etc. (cont.) > > 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. > Two comments: * Forwarding is not the *only* supported result of an Action -- it is simply the most common. An Action can create the response itself (either directly, or by calling a Velocity template or whatever) and then return null instead of an ActionForward instance, and the controller servlet will assume that the response has already been created. * It's clearly feasible to forward to some servlet that calls the Velocity template that you want to use to display the result. > >>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. > The current (EA2) version of i18n in JSTL is based on ResourceBundle, which clearly gives you the option to access the underlying message strings via an API. I don't see any reason that Struts would ever de-support API-based access to the messages, because sometimes you need them in a Action instance as well. > >>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 disagree with what I think you are saying. Struts follows the J2EE convention that data sources are configured on a per-webapp basis. The details of exactly what database is being accessed (and the database username/password being used) can be easily made external to the webapp itself by using the standard data source support of your app server. (Tomcat 4 supports this for non-EJB apps in a compatible manner.) The "pool" package in Jakarta Commons is pretty generic, as is the "dbcp" package built on topof it. What extra layering would you like to see? > I agree about the datasources and the servlet context. > > Thanks again for the response, > > Donnie > Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
