Apologies for my Australian-ism - but your subclass structure is bullshit :)
Why do that? It's far too complex. Just have doCreate(), doRead() etc and
use the code as is. This is exactly what it was designed for?
And as for your analysis of AS - exactly correct, except for the interceptor
bit. It's best done as a concrete class I think.
M
On 3/7/03 9:57 AM, "Matt Ho" ([EMAIL PROTECTED]) penned the words:
>> Well, there are tonnes of use cases for this (you are talking about
>> commands right?)
>>
>> The most commonly quoted one is a CRUD action. You create different
>> methods like doCreate(), doUpdate() and have the same fields (ie name,
>> email etc).
>
> Ha! I've definitely spent too much time with Struts :)
>
> It strikes me that if you want to combine the CRUD into a single class,
> you could do it as follows. It's not a short as a single class, but I
> think this is far easier to follow.
>
> I can simply use ReservationAction.Create, ReservationAgent.Read, etc in
> my xwork file as appropriate and the functionality of the class is a lot
> more clear than it would be otherwise :)
>
> public abstract class ReservationAction implements Action {
> private ReservationAgent agent;
> public ReservationAction(ReservationAgent agent) {
> this.agent = agent;
> // do other stuff
> }
>
> // do other stuff here
>
> public static class Create extends ReservationAction {
> public String execute() {
> ...
> }
> }
>
> public static class Read extends ReservationAction {
> public String execute() {
> ...
> }
> }
>
> public static class Update extends ReservationAction {
> public String execute() {
> ...
> }
> }
>
> public static class Delete extends ReservationAction {
> public String execute() {
> ...
> }
> }
> }
>
> The topic of workflow reminded me of struts discussions a while back on
> the same topic. I don't think struts ever came up with a good solution,
> but they never had an interceptor stack :)
>
> I'm thinking aloud again ...
>
> It strikes me that doExecute, doValidation, and doDefault could be
> utilized by an interceptor to do all sorts of interestings.
>
> * a view read only page-> doExecute()
> * an input/execute pair of pages would be doDefault -> doValidation /
> doExecute
> * an input/confirm/execute trio would be doDefault -> doValidation ->
> doValidation / doExecute
> * a multipage form would be doDefault -> doValidate(label) ->
> doValidate(anotherLabel) -> doValidate()/doExcute()
>
> ActionSupport could provide default empty implementations for
> doExecute(), doValidate(), and doDefault(). ActionSupport would use a
> WorkflowStrategy to figure out how to traverse the various pages.
> Alternately, you could create an interface that had these method
> signatures and embed the strategy in an interceptor.
>
> However, methinks that this workflow stuff and non-concrete actions may
> not mix well.
>
> Thoughts?
>
> M
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
