Struts extensibility, multiple servlets, etc. (cont.)

[Donnie Hale <do...@haleonline.net>]

Folks,

I know I'm jumping in late here, so please forgive me if I'm rehashing too
much old material, stepping on toes, etc. I've spent the last day or so
spelunking much of the ActionServlet and related code with an eye toward
extensibility. My motivation is adapting/extending Struts, preferably
without changes to its core source code (via non-committed changes), to
support Velocity as the view-rendering mechanism. I don't want to get into a
p***ing contest about JSPs vs. Velocity, etc. I'll also add that I took a
quick look at the ServiceManager stuff as well. Lastly, I did look at the
enhancement comments for the 1.0.1 release.

Here are some observations, etc.

- An implicit (or explicit) Struts premise, JSPs, results in a
predisposition to assume RequestDispatcher.forward is OK for every
app/view-rendering solution. For example, processValidate expects to be able
to forward if validation fails.

- The points in ActionServlet.process at which functionality can be
overridden are fragile, as you either have to call "super" or duplicate code
to get the current functionality plus add in your own.

- It seems odd to have code in ActionServlet.process specifically tied to
Forwarding/Redirecting ActionForwards. It would seem to be more "OO" to have
a virtual method on ActionMapping and/or ActionForward to achieve this in
the event that other types of ActionForwards need created.

I guess what I'd like to see is a decoupling of ActionServlet from the
"template method pattern" it attempts to follow (i.e. formalize the pattern
by specifying an interface). At the same time, I'd like to see the action /
action form / mapping decoupled from any assumptions about view rendering.
So we can keep all the great stuff for pre-populating beans, declarative
actions and mappings, etc.; but parameterize the mechanisms for initiating
the rendering of the view.

- A side effect of assuming forwarding is that lots of stuff gets put in the
various contexts (servlet, session, request). Just by looking at the key
names in Action.java, you can't tell which of those contexts to find them
in. I've thought that perhaps having a single object for each of those
contexts, accessible by name from those contexts, might be more flexible and
maintainable. For example:

class StrutsServletContext { ... }
getServletContext().setAttribute("org.apache...SERVLET_CONTEXT", // instance
of StrutsServletContext);

The StrutsServletContext class would have accessors for the message
resources, data sources, etc. Use the same pattern for request and session
contexts. I'm not sure, but I think that might ease moving to the multiple
controller support that's been discussed recently.

- I see that Digester has moved into Commons. Has any consideration been
given to moving MessageResources, etc. there? It seems like it's the kind of
self-contained, decoupled, reusable functionality that could go there.

Thanks for bearing with me. :)

Donnie


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Struts extensibility, multiple servlets, etc. (cont.)

[Incze Lajos <in...@mail.matav.hu>]

On Fri, Nov 23, 2001 at 06:25:54PM -0500, Ted Husted wrote:
> Donnie Hale wrote:
> > 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.
> 
> In what way would you like them to act on themselves? Initially, the
> ActionForward is a way to give a URI a logical name. The ActionServlet
> asks for a path, and it is given a path in return. Of course, how that
> path is generated is the ActionForward's business. It's really a type of
> event object.

I think he says that instead of saying dispatcher forward ActionServlet
should call the forward method of the ActionForward object. This way
the rendering could be decoupled from the JSP. In fact it can be achieved
today. If action returns a null, then it means  that ActionServlet will
not bother to dispatch the next view. Anyway, what Donnie Hale is asking
seems to me more generic.

> > 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.
> 
> Would it be possible to provide the Velicity service as another servlet
> in the application?
> 
> The ActionForward paths could then equate to a Velocity template. 
> 
> The VelocityAction would build the context, or gather the details
> required to do do, and pass it to the VelocityServlet in the request.
> 
> This would be very like the current pattern, since JSPs are a type of
> servlet being rendered by a service (i.e. Jasper) that Struts does not
> control. So instead of forwarding to Jasper, we are forwarding to a
> VelocityServlet.
> 
> Of course, it is also possible to equip an Action with the
> Velocity-supporting services, and have it render the response, and
> return null to the ActionServlet. But forwarding to a VelocityServlet
> makes the most sense from a patterns perspective, since, technically,
> the ActionServlet should not be handling this itself.

I couldn't catch this. ActionServlet would do the same thing with the
ActionForward object what it does with the ActionBean or Action itself.
It woud call a generic forward method (as it calls a generic validate,
reset, process method). Even it seems to me more symmetric tha the current
procedure.

> > That aounds great, as long as I don't have to use tags to interact with
> > MessageResources.
> 
> The MessageResources are now exposed as a bean in the ServletContext,
> and so anyone with a link to the ServletContext can access them,
> including an Action or another Servlet. So, the Velocity Action could
> ask for the text for a given token for a given locale (from the user's
> session), and merge it into the template.
> 
> If someone wanted to take this class to the Commons, with the idea that
> Struts, Velocity, and the i18n tags could all share it, I doubt that
> anyone here would object.
> 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/struts/

incze

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Struts extensibility, multiple servlets, etc. (cont.)

[Ted Husted <hu...@apache.org>]

Donnie Hale wrote:
> Well, as I've said, I certainly understand that point of view. I probably
> lean that direction, if not just for the sake of clarity of responsibility.
> But from a pure flexibility point of view, requiring forwarding is
> constraining.

Forwarding is not required. Another approach would be a base
VelocityAction that did whatever the VelocityServlet would do. If the
Action returns null, the ActionSerlvet is satisifed.

But to get best use out of the framework, a view rendering system that
maps to an URI, and can access the Message Resources, is optimal. This
could be used as a drop-in replacement where Struts developers now use
JSPs. 

The Struts tag extensions are coupled with JSPs, but everything else in
the framework is neutral. There is a premise is that the view-rending
system can be accessed via a URI, and any system that does this will
work as well as (or along with) JSPs. 

If I had a couple of PDF's to render, I'd probably use a PDFAction. If
the whole application were PDFs, then I would probably go with a
separate PDF servlet. In practice, there would probably not be any real
difference between the two. Just a matter of where you want to park the
code.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Struts extensibility, multiple servlets, etc. (cont.)

[Donnie Hale <do...@haleonline.net>]

Hi, Ted.

>>It seems reasonable, though it's not something that would scatch any of
my own itches right now ;-)<<

I understand that. It seems like a lot of focus right now is on adding
better support at the app level as opposed to at the framework level. That
probably means that the framework is 80% right or better. :)

>>I would say that if there's a lot of view rendering to be done, then the
place to do it would be through a servlet devoted to this task. This
permits the highest degree of reusablity, and could be used in other
frameworks besides Struts.<<

Well, as I've said, I certainly understand that point of view. I probably
lean that direction, if not just for the sake of clarity of responsibility.
But from a pure flexibility point of view, requiring forwarding is
constraining.

>>But that does not fit well with my personal view of how a model 2
architecture should
work.<<

Model 2 dictates logical separation of the V from the M & C. How an
implementation achieves it is left as an exercise to the reader. :)

Donnie


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Struts extensibility, multiple servlets, etc. (cont.)

[Ted Husted <hu...@apache.org>]

Donnie Hale wrote:
> I hope I'm making sense. :)

It seems reasonable, though it's not something that would scatch any of
my own itches right now ;-)


> >>Would it be possible to provide the Velicity service as another servlet
> in the application?<<
> 
> Absolutely, that's what Geir's example does. And that seems to be the
> direction most Velocity folks desire. I understand their viewpoint. I
> suppose I'm just making the more general point that forwarding isn't
> required to have action-processing and view-rendering be decoupled. Perhaps
> Struts should allow for that. Or perhaps Struts would rather put a stake in
> the ground that forwarding is the preferred mechanism for invoking
> view-rendering (and I can see the case for that, too).

I would say that if there's a lot of view rendering to be done, then the
place to do it would be through a servlet devoted to this task. This
permits the highest degree of reusablity, and could be used in other
frameworks besides Struts. 

As it stands, a developer can provide a response from the Action and
return null to the ActionServlet. This is useful for smaller jobs, and I
would say to use the method best suited for the circumstances. 

Once the ActionServlet has better services support, it's entirely
possible that a response could be returned there as well. But that does
not fit well with my personal view of how a model 2 architecture should
work.

-T.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Struts extensibility, multiple servlets, etc. (cont.)

[Donnie Hale <do...@haleonline.net>]

Ted,

Again, I appreciate the response(s).

>>
In what way would you like them to act on themselves? Initially, the
ActionForward is a way to give a URI a logical name. The ActionServlet
asks for a path, and it is given a path in return. Of course, how that
path is generated is the ActionForward's business. It's really a type of
event object.
<<

There's code in the ActionServlet of the form:

    // Execute a forward if specified by this mapping
    if (!processForward(mapping, request, response))
        return;

    // Execute an include if specified by this mapping
    if (!processInclude(mapping, request, response))
        return;

So we have two calls directly tied to mappings which have known subclasses
of ActionForward. It's "known" (i.e. coupling) that those mappings don't
have Actions and we can skip that stuff. If we get past this in the
ActionServlet, the implicit assumption is that we have a mapping with an
Action and we can go ahead with dealing with the Action, getting the
ActionForward back from it, etc.

It seems to me it would be more flexible and natural if ActionServlet
invoked a method on the ActionMapping that always returned an ActionForward.
The ActionMapping would be responsible for building and calling an Action
when appropriate but in any case would simplify the ActionServlet. As I
think about it, it seems that there should be a Mapping base class from
which ActionMapping is derived. The Forward/Include derivations should be
Mapping derivations which don't have Actions - they just return the
corresponding ActionForward. ActionMapping is a Mapping that does have an
Action and would invoke it:

Mapping
  ForwardingMapping
  RedirectingMapping
  ActionMapping

Code in the ActionServlet would be:

    ActionForward forward = mapping.execute(/* stuff */);

ActionMapping.execute() would retrieve the Action and call perform() on it,
returning what it returns. ForwardingMapping.execute() (and
RedirectingMapping.execute()) would simply return the correct derived
ActionForward classes with the configured path. At that point, other types
of mappings become, if you will, first class citizens and can do whatever
they want but still return an ActionForward.

I hope I'm making sense. :)

>>Would it be possible to provide the Velicity service as another servlet
in the application?<<

Absolutely, that's what Geir's example does. And that seems to be the
direction most Velocity folks desire. I understand their viewpoint. I
suppose I'm just making the more general point that forwarding isn't
required to have action-processing and view-rendering be decoupled. Perhaps
Struts should allow for that. Or perhaps Struts would rather put a stake in
the ground that forwarding is the preferred mechanism for invoking
view-rendering (and I can see the case for that, too).

Take care,

Donnie


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Struts extensibility, multiple servlets, etc. (cont.)

[Ted Husted <hu...@apache.org>]

Donnie Hale wrote:
> 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.

In what way would you like them to act on themselves? Initially, the
ActionForward is a way to give a URI a logical name. The ActionServlet
asks for a path, and it is given a path in return. Of course, how that
path is generated is the ActionForward's business. It's really a type of
event object.

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

Would it be possible to provide the Velicity service as another servlet
in the application?

The ActionForward paths could then equate to a Velocity template. 

The VelocityAction would build the context, or gather the details
required to do do, and pass it to the VelocityServlet in the request.

This would be very like the current pattern, since JSPs are a type of
servlet being rendered by a service (i.e. Jasper) that Struts does not
control. So instead of forwarding to Jasper, we are forwarding to a
VelocityServlet.

Of course, it is also possible to equip an Action with the
Velocity-supporting services, and have it render the response, and
return null to the ActionServlet. But forwarding to a VelocityServlet
makes the most sense from a patterns perspective, since, technically,
the ActionServlet should not be handling this itself.

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

The MessageResources are now exposed as a bean in the ServletContext,
and so anyone with a link to the ServletContext can access them,
including an Action or another Servlet. So, the Velocity Action could
ask for the text for a given token for a given locale (from the user's
session), and merge it into the template.

If someone wanted to take this class to the Commons, with the idea that
Struts, Velocity, and the i18n tags could all share it, I doubt that
anyone here would object.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Struts extensibility, multiple servlets, etc. (cont.)

[Ted Husted <hu...@apache.org>]

"Craig R. McClanahan" wrote:
> 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.)

I'm just running cold on Struts being in the connection-pool business.
When we added this, there wasn't another place to put it or a ready
alternative. Neither of these statements are true anymore. The recent
release of Poolman work very well with Struts, and can be access from
the business layer. I'm sure there are now others as well.

And, as you know, the connection pool breu-ha-ha is why we founded the
Commons. I would like to see it moved, or deprecated and have the docs
suggest other likely products. I'd move it myself, but I'm not
particularly interested in supporting it afterwards. I do agree that
anything we suggest should follow J2EE conventions, support datasources
directly, and also work well with the Jakarta Taglibs dbTags.

>From a pure technical perspective, since there is not a portable way to
expose our connection pool outside the ServletContext, I feel that it
sends the wrong message to developers, just as having ActionForm as an
interface sent the wrong message. 

Of late, it has become a support burden, and I don't see committers
stepping up to the plate to answer the difficulties people report when
using the Generic Pool in a production environment. (Probably because
none of us are.) Struts is now considered a production tool, and
anything we distribute should meet that standarfd.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Struts extensibility, multiple servlets, etc. (cont.)

["Craig R. McClanahan" <cr...@apache.org>]

See intermixed.

On Fri, 23 Nov 2001, Donnie Hale wrote:

> Date: Fri, 23 Nov 2001 11:25:15 -0500
> From: Donnie Hale <do...@haleonline.net>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Struts extensibility, multiple servlets, etc. (cont.)

[Donnie Hale <do...@haleonline.net>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Struts extensibility, multiple servlets, etc. (cont.)

[Ted Husted <hu...@apache.org>]

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. 

Donnie Hale wrote:
> Here are some observations, etc.
> - An implicit (or explicit) Struts premise, JSPs, results in a
> predisposition to assume RequestDispatcher.forward is OK for every
> app/view-rendering solution. For example, processValidate expects to be able
> to forward if validation fails.

JSP's are not a design goal, but simply the domain that interested the
orignal workers. Forwarding and redirecting is how HTTP generally works,
so that became the default approach.


> - The points in ActionServlet.process at which functionality can be
> overridden are fragile, as you either have to call "super" or duplicate code
> to get the current functionality plus add in your own.

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


> - It seems odd to have code in ActionServlet.process specifically tied to
> Forwarding/Redirecting ActionForwards. It would seem to be more "OO" to have
> a virtual method on ActionMapping and/or ActionForward to achieve this in
> the event that other types of ActionForwards need created.

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


> I guess what I'd like to see is a decoupling of ActionServlet from the
> "template method pattern" it attempts to follow (i.e. formalize the pattern
> by specifying an interface). At the same time, I'd like to see the action /
> action form / mapping decoupled from any assumptions about view rendering.
> So we can keep all the great stuff for pre-populating beans, declarative
> actions and mappings, etc.; but parameterize the mechanisms for initiating
> the rendering of the view.

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.


> - A side effect of assuming forwarding is that lots of stuff gets put in the
> various contexts (servlet, session, request). Just by looking at the key
> names in Action.java, you can't tell which of those contexts to find them
> in. I've thought that perhaps having a single object for each of those
> contexts, accessible by name from those contexts, might be more flexible and
> maintainable. For example:
> 
> class StrutsServletContext { ... }
> getServletContext().setAttribute("org.apache...SERVLET_CONTEXT", // instance
> of StrutsServletContext);
>
> The StrutsServletContext class would have accessors for the message
> resources, data sources, etc. Use the same pattern for request and session
> contexts. I'm not sure, but I think that might ease moving to the multiple
> controller support that's been discussed recently.

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. 


> - I see that Digester has moved into Commons. Has any consideration been
> given to moving MessageResources, etc. there? It seems like it's the kind of
> self-contained, decoupled, reusable functionality that could go there.

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.

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. 


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>