Would it be XW-440? * http://jira.opensymphony.com/browse/XW-440
-T. On 11/21/06, Don Brown <[EMAIL PROTECTED]> wrote:
I'd say result selectors and WW-1393 are different. WW-1393 has been implemented, but result selectors have not, AFAIK. I don't remember the XWork ticket, off-hand, but the change involved DefaultActionInvocation I believe. Don Ted Husted wrote: > Is "Result Selectors" what was covered by WW-1393? > > * http://issues.apache.org/struts/browse/WW-1393 > > Or, was that a different feature? > > Our WW-1393 says it was handled on the XWork end, but doesn't cite a > ticket. I don't know what we actually did. > > Did we > > * Implement result selectors? > > * Implement " Returning Result directly"? > > Or, are they the same thing? > > -Ted. > > On 10/30/06, Don Brown <[EMAIL PROTECTED]> wrote: >> I really, really, like this idea, especially since it doesn't introduce >> any new syntax or complications for the 90% of users that don't need >> this. The more we can keep Struts/XWork to simple, internal components, >> the easier it will be to worth with both as a user and as a developer. >> >> This would make a nice plugin with default result types for common >> situations. >> >> Don >> >> Ted Husted wrote: >> > On 10/26/06, Don Brown <[EMAIL PROTECTED]> wrote: >> >> Then, each result selector is given a chance to select a single >> String. >> >> If a result has when="modern-browser,partial-html", >> >> the each selector will be given a chance to return its "when" >> token, and >> >> xwork will match them together as AND. >> > >> > Or, with wildcards ... >> > >> > <result-type name="selector" class="o.a..d.SelectorResult" > >> > <param name="matchers" class="o.a.s.d.RoleMatcher"> >> > <param name="matchers" class="o.a.s.d.AgentMatcher"> >> > <param name="wraps" class="o.a.s.d.ServletDispatcherResult> >> > </result-type> >> > >> > <action name="*" class="mypackage.{1}"> >> > >> > <result type="selector">/{1}{result-code}{role}{agent}.jsp</result> >> > >> > <result name="error">/{1}-error.jsp</result> >> > >> > </action> >> > >> > Each "matcher" could add a named token into the context, like >> > "-manager". The selector result could then resolve the wildcard path >> > and delegate to another Result, like the default ServletDispatcher >> > Result. The matchers might not inject a token, if it was the default >> > or didn't apply for some reason. >> > >> > So, an application using this strategy might have pages named like. >> > >> > * ViewFoo.jsp >> > * ViewFoo-netscape4.jsp >> > * ViewFoo-manager.jsp >> > * ViewFoo-manager-netscape4.jsp >> > * ViewFoo-failure.jsp >> > >> > Of course, this strategy presupposes using something like SiteMesh or >> > Tiles to provide the standard layout, so that each "page" can just >> > focus on it's own content. >> > >> > -T.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
