Great, I like this interceptor stuff, looks cool. Have a couple of doubt though:
1. Can the interceptor affect the view mapping in anyway ? 2. How about providing different view base on client device. For e.g, providing different view for html, xml, wml, xul, etc. 3. Can a package depends on more than one package ? 4. I don't really understand why the interceptor stack ( the interceptors tag ) is nested inside the package tag. It seems like the idea is we can construct an interceptor stack from multiple package. 5. May be there should be a packages tag so that we can package multiple dependent package together. 6. It seems like there could be many place that we can have name collision issue. Not sure whether this is a major issue, may be we need some namespace mechanism here. 7. Would like to see some sort of mechanism to pass some initialization parameter to the action. ( like the init param thing in servlet configuration ) 8. Is there anything in the config that would define the scope of the interceptor ( for e.g, pre/post action execution, pre/post entire action chain execution, etc ) ? Btw, just curious if u already using an AOP framework, wouldn't all this webwork-interceptor stuff redundant for u ? Regards, Low --- Rickard Öberg <[EMAIL PROTECTED]> wrote: > 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 > > -- > 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 __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.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
