OK, do you remember how the WW-1393 feature works, or where we test it?
-Ted. On 11/21/06, Don Brown <[EMAIL PROTECTED]> wrote:
Nope, that's something different. Perhaps I didn't open up a ticket on that, and just referred the commit to the struts one. Don Ted Husted wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- HTH, Ted. * http://www.husted.com/struts/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
