> > If Struts is to move to being used as a generic MVC
> > architecture that can be used in a wide range of other
> > environments it may be appropriate to consider 'abstracting'
> > the request and response objects (or at least provide an
> > option to) to isolate them from the HTTP protocol. Otherwise,
> > Struts will likely remain tied to J2EE 'Web Applications'
> > (which I'm not saying is a bad thing). In fact, the value of
> > Struts as a "web application framework" may be great enough
> > that the creation of a generic MVC framework may better be
> > made a Commons project - if there is a desire to do this at all.
> >
> I do this currently by a special base Action class that provides a
> handleRequest( UserRequest) which offers all methods for getting
> parameters, attributes, etc. without passing around all those HTTP
> references.. I had talked to Craig about this a while back, and he was
> concerned - for good reason - with backwards compat. If 2.0 is going to
> rip up and rebuild with new servlet technologies and other epiphanies
> over the last 2 years, I would so love to see this abstraction. It would
> make unit testing easier (yes, I've seen the frameworks out and they are
> fine for 1.0/1.1) and just make Struts into a more generic MVC model for
> things like Desktop GUIs and Web Services.
I'd say that this is the best approach - maintain 2 base Action classes.
In fact, it might be worth considering the creation of an 'interface' (or
factory approach, or something) that allows different people to 'plug'
different base Action classes. If it were possible for you to provide your
Action class (for example) in a manner that you met some sort of 'contract'
(be it an interface or whatever), then we'd find all sorts of people
creating base Action classes to tie Struts into all sorts of environments.
Then backward compatibility could be met by simply having one of the Action
class 'options' be backward compatible.
Right now, the ActionServlet extends HttpServlet - this ties struts to J2EE
web applications pretty tightly.
The only way to break this bond would be to have it 'implement' an
interface as its primary responsibility. If you wanted the framework to be
webapp oriented, it could extend HttpServlet as well - but this would have
to be 'not required'.
This is a pretty dramatic change... and unlikely unless someone builds it
and generates support for it. This is 'revolution', not 'evolution'.
> > I've already built a 'command pattern' prototype based on
> > Axis that minimizes the need to define new WSDL for each Web
> > Service 'endpoint' you want to define. We could potentially
> > create a standard WSDL definition that is flexible enough to
> > handle a pretty wide range of applications and then build a
> > backend that maps the web sevice 'command' to a Struts form
> > bean/Action class combination. This would allow you to build
> > web service 'command processors' by implementing Action
> > classes. I've got a lot of the design already in my head.
> >
> That rocks! I have the same time constraints but would love to see this
> come to fruition!
Maybe I'll look into creating a space on sourceforge for this. Let me look
over what I have.
Kevin
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure. If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---------------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
