> -----Original Message-----
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: 17 December 2003 23:00
> To: Struts Developers List
> Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
>
==////==
>
> > A sort of meta-question: When is Struts no longer Struts? I
> mean, how much
> > change can we introduce in Struts 2.0 before it becomes so
> different that
> > it's really a different framework? Do we need to decide on
> what Struts is,
> > and is not, before we go too far down the path of Struts
> 2.0? Or do we let
> > whatever falls out just fall out and deal with it later?
>
> Legally, I'd say that Strut is whatever the Struts Community
> says it is.
> It's a brand that belongs to the ASF, which we manage on the
> Foundation's behalf.
>
> Technically, I'd say that Struts (or any framework) is an
> aggregation of
> its components. In Struts 1.0, we had mainly Form, Forward, Mapping,
> Action, and Messaging components. In Struts 1.1, we added Exception,
> Validation, Composite (or Tile), and PlugIn components.
>
> So long as Struts 2.x retains the same hallmark components in a
> recognizable form, I'd say it's still Struts. :)
>
> Overall, it's my feeling that Struts does all the right things, it's
> just that we don't do them in all the right places. :) Being able to
> extend elements is one example. Encapsulating paths is another.
>
> My own goal for Struts 2.x is to consistently apply all our best
> practices and eliminate inconsistent and legacy practices.
> We've got a
> good thing here; we just need to make it even better. :)
>
> In terms of new functionality, the three biggest fish I'd like to fry
> are Workflow, SSL, and Unit Testing. Towards that end, I'd like to
> consider integrating LivingLogic's Workflow, ssl-ext, and Struts
> TestCase into the Struts 2.x development stream. We may also want to
> consider adding these as standard options to Struts 1.x, so
> as to blaze
> a trail.
Integrating StrutsTestCase would help with the Unit tests,
although it will have to be heavily modified in parallel
to keep up with changes in development.
>
> Although it's not evident from the Jericho DTD, the intention
> is to use
> a Context object in the signatures, perhaps the Commons Chain
> Context,
> so as to encapsulate Servlet/Portlet dependencies.
>
So you no longer going to pass in request and response objects
around, but instead have a context instead. Maybe it would
be a little inconvenient for every Action to call
``context.getRequest()'' all the time. Perhaps we can keep them
please. I dont mind losing the form bean. I could live with
``context.getForm()'', because for some environments you dont
need to buffer a user's input. e.g. web services, or even
a flat file.
public ActionForward someStateAction(
org.apache.commons.chain.Context context,
some.generic.request request,
some.generic.response response );
And for those of us who have subclassed Action, and ActionForm
to create our own super frameworks, this will be very
interesting and involved work to say the least/.
> -Ted.
>
--
Peter Pilgrim,
Struts/J2EE Consultant, RBoS FM, Risk IT
Tel: +44 (0)207-375-4923
***********************************************************************************
The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered
Office: 36 St Andrew Square, Edinburgh EH2 2YB.
Authorised and regulated by the Financial Services Authority
This e-mail message is confidential and for use by the
addressee only. If the message is received by anyone other
than the addressee, please return the message to the sender
by replying to it and then delete the message from your
computer. Internet e-mails are not necessarily secure. The
Royal Bank of Scotland plc does not accept responsibility for
changes made to this message after it was sent.
Whilst all reasonable care has been taken to avoid the
transmission of viruses, it is the responsibility of the recipient to
ensure that the onward transmission, opening or use of this
message and any attachments will not adversely affect its
systems or data. No responsibility is accepted by The Royal
Bank of Scotland plc in this regard and the recipient should carry
out such virus and other checks as it considers appropriate.
Visit our websites at:
http://www.rbs.co.uk/CBFM
http://www.rbsmarkets.com
********************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
