Heng Sin Low wrote:
Yes, interceptors can shortcut the mapping just like a servlet filter can shortcut a servlet rendering. For example, a security interceptor could shortcut an action execution and return LOGIN which causes the login form to be displayed.Great, I like this interceptor stuff, looks cool.Have a couple of doubt though: 1. Can the interceptor affect the view mapping in anyway ?
The Portlet API uses the following convention, which might be interesting. From PortletContext.include():2. How about providing different view base on client device. For e.g, providing different view for html, xml, wml, xul, etc.
"For example, a jsp file "/myportlet/mytemplate.jsp" will be searched for
* in the following order, when accessing via HTML-Browser:
* 1. /html/en/US/IE/mytemplate.jsp
* 2. /html/en/US/mytemplate.jsp
* 3. /html/en/mytemplate.jsp
* 4. /html/mytemplate.jsp
* 5. /en/US/IE/mytemplate.jsp
* 6. /en/US/mytemplate.jsp
* 7. /en/mytemplate.jsp
* 8. /mytemplate.jsp"
(http://cvs.apache.org/viewcvs/jakarta-jetspeed/scratchpad/portlet-api/src/org/apache/jetspeed/portlet/PortletContext.java?rev=1.1&content-type=text/vnd.viewcvs-markup)
We could do something similar here.
3. Can a package depends on more than one package ?
Yes, that was the idea.
Everything is defined inside a package. This allows for encapsulation between packages as well as easy inclusion.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.
Not sure how you mean... if you want several packages together simply include them all using XML entities, or make an XML file with the packages you want.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.
The idea is that the packages provide for namespaces.
The problem is that since actions are initialized on each invocation that would lead to a LOT of initialization and/or reflection. Not a good idea.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 ) ?
The interceptor stacks effectively do that.
Nope. This is a more specialized case which is perfect for this particular usage, and the surrounding framework is also specialized for it.Btw, just curious if u already using an AOP framework, wouldn't all this webwork-interceptor stuff redundant for u ?
Same idea, different implementation.
/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