> -----Original Message-----
> From: Erik Hatcher [mailto:[EMAIL PROTECTED]
> > >
> > See, but there's the problem I had with WW1.x... You had
> configuration
> > constructs for Commands, but the whole CommandDriven stuff was
> > implemented in ActionSupport. This needs to be core in
> configuration,
> > and it needs to be core in the framework.
>
> Ya lose me with comparisons to WW1.x since I have never used
> it, sorry.
The idea is that we had stuff for configuring multiple entry points in
the config file (core) but the actual implementation was a detail of the
way ActionSupport was implemented.
>
> But aren't you subclassing something already?
> ActionSupport? Or your
> actions are truly POJO's with no base class?
I probably WOULD subclass ActionSupport, but if I have a reason NOT to,
I don't want to lose core functionality.
>
> I hear what you are saying loud and clear. I don't want to keep
> bringing up Struts, as I want to put it out of my mind, but Action in
> Struts is a base class. Evil! It should have been an interface from
> the start. Subclassing Action then gets you into trouble because
> eventually you'll want to leverage ForwardAction, or
> DispatchAction, or
> the wonderful LookupDispatchAction :). But since you've done the
> BaseAction construct you're screwed except for delegation somehow, or
> doing multiple BaseXXXAction subclasses which is hideous.
>
> You would not need to subclass in WW2 to get dispatching like
> you want.
> Implement Action, have a setMethod, and key off method in
> execute().
> I see your point that you'd have to do that in all your actions that
> dispatch, and thus we're now back to subclassing to centralize.
>
> Can we see what your actions look like and how they work so I can see
> your use-case (err... user story!)? Most of my web apps
> simply have a
> single action and dispatching is not something I've had much
> need for,
> but maybe its because my apps are just more simplistic than yours?
It's very useful for CRUD actions:
public String edit() {
try {
model = persistenceManager.load(MyClass.class, id);
} catch (Exception e) {
addActionError(e.toString());
return ERROR;
}
return SUCCESS;
}
public String save() {
try {
persistenceManager.save(model);
} catch (Exception e) {
addActionError(e.toString());
return ERROR;
}
return SUCCESS;
}
Public String delete() {
try {
persistenceManager.delete(MyClass.class, id);
} catch (Exception e) {
addActionError(e.toString());
return ERROR;
}
return SUCCESS;
}
>
> > Well, this is not exactly the same. I don't want to be
> loose with data
> > types or anything like that. Reflective method calls are a
> pretty well
> > understood and low-risk technology.
>
> My main argument against making it truly dynamic like it is
> now is the
> cross-referencing needed to find out the flow and how an action is
> working. Someone (Patrick?) mentioned this earlier. I also like the
> idea of the _pure_ command pattern. Like I've said though, I'm still
> learning and your discussion is persuasive. Inheritance is
> the last OO
> thing we want to burn up, so I'm in complete agreement with you on
> avoiding it - this is why I'm cringing with ActionSupport and
> such....
> rather than letting smarter interceptors take care of some of that
> (like rejecting execute() when validation fails - would making this a
> parameter on the builtin interceptor be reasonable? Or a
> separate one
> to do that?).
>
> Erik
Either one of those would work. The reason I was talking about a
separate interceptor for short-circuiting the processing was because you
might have different validator interceptors... We've got the one now
that looks up validations via XML files, but we could also have one to
call a validate() method on the action... Then we'd need the same check
for errors and return INPUT for both of these... Instead it could be one
DefaultWorkflowInterceptor that you apply after these.
Jason
-------------------------------------------------------
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
