Copmments: - <interceptor-ref name=""> is ugly XML! Why not just <interceptor ref="" /> ? It's obvious that the name="" attribute refers to the name of an interceptor from the tag name - is there a global package? - how are parameterised actions handled? (one of the other main xwork goals?)
Looks good otherwise. -mike On 2/1/03 10:18 PM, "Rickard Öberg" ([EMAIL PROTECTED]) penned the words: > I'm fiddling with the action configuration XML, and here's what I have > currently. > > <xwork> > <package name="standard" prefixes="com.opensymphony.xwork"> > <interceptor name="parameter" > class="action.interceptor.ParameterInterceptor"/> > > <interceptors name="default"> > <interceptor-ref name="parameter"/> > </interceptors> > > <result name="error" view="error.jsp"/> > </package> > > <package name="examples" depends="standard" > prefixes="com.opensymphony.xwork.action"> > > <result name="error" view="exampleerror.jsp"/> > > <action name="foo" class="SimpleAction"> > <interceptors-ref name="default"/> > <result name="success" view="bar.action"/> > </action> > > <action name="Bar" class="SimpleAction"> > <interceptors-ref name="default"/> > <result name="success" view="success.jsp"/> > </action> > </package> > > <package name="examples2" depends="standard" > prefixes="com.opensymphony.xwork.action"> > > <action name="foo" class="SimpleAction"> > <interceptors-ref name="default"/> > <result name="success" view="bar.action"/> > </action> > > <action name="Bar" class="SimpleAction"> > <interceptors-ref name="default"/> > <result name="success" view="success.jsp"/> > </action> > </package> > </xwork> > -- > > There are a couple of core ideas here. The first is the introduction of > packages. This allows a single XML file to be built up of many > individually developed packages. Typically one would use XML entities to > refer to them, so the base XML file would typically look like this: > <xwork> > &standard; > &examples; > &examples2; > </xwork> > where those entities refer to the individual package files. It might > even be a good idea to use a default entity resolver which understands > .xml suffixes so one doesn't have to declare those entities: > <xwork> > &standard.xml; > &examples.xml; > &examples2.xml; > </xwork> > and here it would also be possible to add a standard entity resolver > that understands properties files: > <xwork> > &standard.xml; > &examples.xml; > &examples2.properties; > </xwork> > so that simple packages can be defined using the old format. > > By using XML entities one can easily put several independent packages > together into one coherent application. > > The next highlight is the notion of package specific prefixes. Pretty > obvious what they're for I hope. Next up is the "depends" attribute, > which is used to declare what packages it "builds on", and this is > mainly in order to do interceptor referencing. There will usually be a > standard package with common interceptors and interceptor stacks (as > shown above), and these can then be referenced easily, and > application-specific interceptors can be introduced in ones own package. > One can even override stacks and interceptors this way: > <package name="examples" depends="standard" > prefixes="com.opensymphony.xwork.action"> > <interceptor name="mystuff" class="MyInterceptor"/> > > <interceptors name="default"> > <interceptor-ref name="mystuff"/> > <interceptors-ref name="default"/> > </interceptors> > > <action name="foo" class="SimpleAction"> > <interceptors-ref name="default"/> > <result name="success" view="bar.action"/> > </action> > </package> > --- > The above would override the "default" interceptor stack from the > "inherited" package. > > We then come to the definition of a single action: > <action name="foo" class="SimpleAction"> > <interceptors-ref name="default"/> > <result name="success" view="bar.action"/> > </action> > --- > The big new thing is the reference to interceptors. Here one typically > does two things: refer to a standard stack of interceptors, and then add > action-specific interceptors that typically only apply to that single > action. This can replace action chaining to a large extent I think. > The result declaration is fairly simple, and is just a mapping from the > string to the resulting view. ".action" is used to trigger chaining, to > the extent that it's still needed. Default mappings can be declared at > the package level (see "error" declarations above), and also follow the > package dependency in order to allow overrides. > > The main idea with packages is hence to both allow for generic behaviour > to be easily utilized, as well as allowing it to be overriden where > necessary, while maintaining a fairly strict semantics. Or that's the > idea anyway :-) > > When it comes to action referencing I haven't made up my mind yet what > is best, but I think it's necessary to use the package name as prefix, > unless an action references another action in the same package. E.g. if > the "foo" action in "examples" wants to chain to "bar" in "examples2" it > would use the name "examples2.bar" instead of just "bar". > > What is missing from this example currently is commands. Any ideas are > welcome here. One option is to have the action declaration look like this: > <action name="fooDefault" class="SimpleAction.doDefault"> > <interceptors-ref name="default"/> > <result name="success" view="bar.action"/> > </action> > > i.e. suffix the class name with the method name. This means that any > public method with a string result (or even void, which would default > the result to SUCCESS) can be invoked. > > Any comments on this? > > /Rickard ------------------------------------------------------- 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
