Philipp Meier wrote:
If you have a JSP that does include of two actions, then using the "command=blah" parameter is going to screw things up.* 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?
For example, I ONLY call WW through includes. I don't have a single page that is called by an .action URL. But that's because I'm writing a portlet engine, and some portlets happen to be WW actions.
Agree. I was referring to the pre-execution-validation. The other stuff we have no control over (and shouldn't have).* 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?
I don't think so. View validation is another beast completely.
I would personally prefer that Update redirects to Show instead, because otherwise a refresh will do the update again. The browser location should never point to an action that "does things".* 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
The action should only refer to the interceptors by logical names, never by classes. And the interceptors should NOT be parameterized in the action definition. I would personally do all of the above configuration through runtime attributes, but any way is ok. It shouldn't be in XWork though (I think).* 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;
}
}
Definitely not. Too much hardcoded stuff, and way way too verbose.
Not straight away. Not quite seeing what is wrong with the current way of doing views which needs to be fixed.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?
/Rickard
--
Rickard Öberg
[EMAIL PROTECTED]
Senselogic
Got blog? I do. http://dreambean.com
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
