On Mon, Dec 30, 2002 at 12:17:25PM +0100, Rickard Öberg wrote: > About the design of XWork.
After staying away from ww for some time I'm happy to comment on this
;-)
> * Commands. Having two actions on a page both using commands doesn't
> work. Generally this feature feels a little weird.
Rickard, I don't really understand what you mean by "two actions on a
page". Could you please explain this to me?
> * Validation. Clunky design, and not enough loosely coupled to the action.
I think Validation is more than one battlefield. There is the
"pre-execution-validation" that is implemented in
ActionSupport.doValidate() and there is validation-during-execution,
e.g. when you business-method signals in invalid input parameter. Due to
the different semantic of the validation (precondition versa
error-signaled) and the different location (command-layer versa
business-logic) the must be handled differently. After all both leed to
a certain "view". Because the view generally depends on the result of
Action.execute(), the second case can be considered as a regular path of
execution and only the precondition should be handled differently.
Additionally I ask myself how we can make the validation constraints
accessible from the view to make validation possible even on the view
layer. But is this reasonable at all?
> * Chaining. IMHO this needs a big rethink, and most of all we need to
> check: what are the usecases to be implemented.
My favourite usecase is the show-edit-update-show usecase. Which means
having the need to pass the primary key of the object updated to the
action show which is the view of the Update action. Views.proptiers
whould look like that:
Show.success=show.xslt
Update.success=Show.action
Show has a form which calls "Update.action" and Show.action needs to be
passed a primary key to specify the object to be shown.
> * Interceptor-style code. The old way was to use base classes to add
> pre/post execution code (security/transaction handling/etc.). Bad bad
> bad, for obvious reasons.
That sounds good and will make the implementation of validation easier.
Still unclear to me is the configuration of this? I can think of two
ways:
1.) "external configuration" which specifies the order of execution of
the actions and interceptors (a little like "PAM" for authorization):
# hypothetic configuration format
<action name="foo">
<action class="org.webwork.action.SimpleValidation>
<param name="field1">Numeric</param>
<param name="field2">String</param>
</action>
<action class="org.webwork.action.web.IsUserInRole">
<param name="role">Admin</param>
</action>
</action>
What I like about this is the high degree of decoupling. What I dislike
about this is the high degree of decoupling ;-) Validation should IMHO
go the the action, because it defines the contract.
2.) "inline configuration".
public interface Action
public String execute() throws Exception;
}
public abstract class SimpleActionBase implements Action {
public abstract String doExecute() throws Exeception;
public String execute() throws Exeception {
for(Iterator i = getActions().iterator; i.hasNext();) {
Action current = (Action) i.next();
copyParamsInto(current);
String result = current.execute();
if (!result.equals(SUCCESS)) {
return result;
}
}
return SUCESS;
}
protected List getActions() {
return actions;
}
public SimpleActionBase() {
actions = new ArrayList();
}
protected List actions;
}
public class Foo implements Action {
public Foo() {
super();
addAction(new UserInRole("admin"));
addAction(new StringValidation("field0", NOT_NULL));
}
public String doExecute() {
...
return SUCCESS;
}
}
> These are the major things I think. Any comments on this? Any other part
> that needs a rethink?
What hasn't been talked about yet is the coupling between Dispatcher and
View. Actually the View consists of a Conversion part which mangled the
actions into another object and the actual view part. I try to make this
clearer with the following example:
Imagine a hypothetical MailDispatcher which pools mail from a mail store
and Dispatches Actions from it. It can use either velocity or xslt or
even jsp as view and use different transports to feed the result into,
e.g. eMail responses or a database or a GSM short message. Common to
the transports. Looking the the mail and the GSM short message transport
is that the can handle a character stream and need an address. The
database transport might persist the result directly as a java object.
The led convertions both transform a java object to a character stream.
This all resembles me of cocoon for those how know it. Im sure we can
make this point clearer. Rickard, any ideas?
Thats all from me for now,
-billy.
--
Meisterbohne Söflinger Straße 100 Tel: +49-731-399 499-0
eLösungen 89077 Ulm Fax: +49-731-399 499-9
msg00873/pgp00000.pgp
Description: PGP signature
