On 8/3/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote:
Ted, Don: what would you guys do in the scenario Jason provided?
I think if we focus on using wildcard patterns to define the better
part of convention-over-configuration, then people can use whatever
patterns work best in a given application.
For the MailReader (just committed), I came up with three core
patterns. One for "prepare" type pages. One for "execute" type pages.
And one for simple "display" pages.
<!-- prepare actions: Confirm/Delete, Edit, Input -->
<!-- A "!" might be a better convention,
but that doesn't seem to work with a button -->
<action name="*/v*" class="mailreader2.{1}.{2}">
<result>/pages/{1}.jsp</result>
</action>
<!-- execute actions: Create, Retrieve, Update, Save -->
<action name="*/*" class="mailreader2.{1}.{2}">
<result name="input">/pages/{1}.jsp</result>
</action>
<!-- display actions: Welcome, Logoff, MainMenu -->
<action name="*" class="mailreader2.{1}">
<result>/pages/{1}.jsp</result>
</action>
I also needed one special-case stanza to handle a case where after
saving, the workflow returns to a caller.
<action name="subscription/Save" class="mailreader2.subscription.Save">
<result name="input">/pages/subscription.jsp</result>
<result type="redirect-action">registration/vInput</result>
</action>
So, just using wildcards, the MailReader went from 14 action elements
to 4, for a logon/logoff parent/child workflow.
To use a single-class with multiple-methods, the key change would be:
<action name="*/*" class="mailreader2.{1}.{2}" method={2}>
<result name="input">/pages/{1}.jsp</result>
</action>
As mentioned, the code is committed to the head.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
