Convention/Annotation Design Patterns (was [s2] Goal - no experimental code in core for 2.1)

[Ted Husted <hu...@apache.org>]

I found that setting default-action-ref to the base support class for
a package solves several problems. It brings in the message resources,
and gives us a way to reference shared properties and other shared
code. So just by adding

    <package name="support" extends="smarturls-default">
    	<default-action-ref name="support"></default-action-ref>
    	<action name="support" class="actions.Support"></action>
    </package>

I was able to eliminate the empty classes and obvious @ActionName
annotations from MailReader Zero (see r186).

This brings SmartURLs father from beta for me, and closer to a GA feature set.

-Ted.


On 10/8/07, Ted Husted <hu...@apache.org> wrote:
> On 10/8/07, Brian Pontarelli <br...@pontarelli.com> wrote:
> >  I think it would also be useful to take a swing at having message bundles
> > that don't require classes (as it sounds like is the current case - although
> > I haven't looked into it). I don't think empty classes should be required at
> > all.
>
> One work-around would be to specify actions/package.properties as the
> struts.custom.i18n.resources.
>
> For now, I'll go ahead and do that and scuttle the empty MRZ classes,
> so that we can be closer to the ideal.
>
> -Ted.

---------- Forwarded message ----------
From: Brian Pontarelli <br...@pontarelli.com>
Date: Oct 8, 2007 3:04 PM
Subject: Re: [s2] Goal - no experimental code in core for 2.1
To: Struts Developers List <de...@struts.apache.org>

 I think it would also be useful to take a swing at having message
bundles that don't require classes (as it sounds like is the current
case - although I haven't looked into it). I don't think empty classes
should be required at all.

 Also, one of my other troubles with things is that handling most CRUD
operations requires a lot of duplication or a single class with two
actions, the insert and update, so that validation and relational id
handling (either single or multiple) are consistent. I think there is
a way to fix this, just need to think about it for a while and
brain-storm on the lists.

 -bp


 Ted Husted wrote:
 I like where SmartURLs is going, but, as it stands, I'd still call it
incomplete and experimental. For an approach like SmartURLs (or
ZeroConfiguration/CodeBehind) to be truly useful, we should be able to
at least write something like the MailReader with a bare number of
ActionName annotations (ideally, 0). I'd also like to try a
zero-config ShowCase application.

I'm trying to find time to review the source code and come up with
some patches. I think if the current list of issues were resolved, I
think it would be a great idea to merge SmartURLs with the new
ZeroConfig/CodeBehind plugin.

Here's a summary list of the missing features I came across trying to
implement MailReader:

SU-5 Support ReST-style parameters
* hello-world/save?message=Howdy == hello-world/save/message/Howdy

SU-6 Extend result-type search scope
* /foo/bar/hello-error.jsp, /foo/bar/error.jsp, /error.jsp, and then
fall back to /foo/bar/hello.jsp

SU-7 Automatically chain action (if any) when branching to other pages
* If Foo.execute returns "bar", we check for FooBar.class

SU-16 Heuristic alias matching
 * for hello-input, (1) HelloInput.execute, (2) Hello.input

I'd also like to review the validation annotations tickets, since
there were some glitches there too (especially with Skip). (Has anyone
compared the XWork validation annotations with the Hibernate
annotations? Are we compatible?)

-Ted.

On 10/8/07, Brian Pontarelli <br...@pontarelli.com> wrote:


 So, should I go ahead and start promoting SmartURLs or should we
continue to attempt to collapse the zero-conf/codebehind stuff into
SmartURLs?

-bp

Re: Convention/Annotation Design Patterns (was [s2] Goal - no experimental code in core for 2.1)

[Ted Husted <hu...@apache.org>]

On 10/9/07, Ted Husted <hu...@apache.org> wrote:
> I tagged a version of MailReader Zero that was using a single
> namespace and (some) multiple methods at
>
>  * http://sq1-struts2.googlecode.com/svn/tags/mailreader-zero-flat/
>
> I've started to refactor the "head" to use multiple namespaces and
> single-method classes, but so far I'm only half done.
>
>  * http://sq1-struts2.googlecode.com/svn/trunk/articles/mailreader-zero/
>

The update MailReader Zero using namespaces is just about done, but
there's one FIXME in actions.subscribe.Index:

// FIXME: Redirecting to an action in another namespace doesn't seem
to work with 0.18.
// also tried a regular redirect with /register/update-input.action
// After redirect, seems to invoking default actions.Support action.
// Using menu for now, but expected to use for each
// @Result(name="cancel", location="update-input",
type="redirect-action", params={"namespace", "/register"}),

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Convention/Annotation Design Patterns (was [s2] Goal - no experimental code in core for 2.1)

[Ted Husted <hu...@apache.org>]

I tagged a version of MailReader Zero that was using a single
namespace and (some) multiple methods at

 * http://sq1-struts2.googlecode.com/svn/tags/mailreader-zero-flat/

I've started to refactor the "head" to use multiple namespaces and
single-method classes, but so far I'm only half done.

 * http://sq1-struts2.googlecode.com/svn/trunk/articles/mailreader-zero/

-Ted.

On 10/2/07, Brian Pontarelli <br...@pontarelli.com> wrote:
> Finally got a chance to look this over. Here's a few things:
>
> 1. You don't need action annotations unless you are actually doing work.
> You can safely hit URLs without actions and only results. I noticed that
> you had a empty Hello action and a number of actions inside classes that
> didn't do anything (i.e. login-input inside Login). My favored pattern
> is to keep it simple like this:
>
> ===== code =====
> package actions;
> @Result(name="success", location="bar", type="redirect-action")
> public class Foo extends ActionSupport {
> }
>
> ===== JSP =====
> WEB-INF/results/foo-input.jsp
>
> Links into the foo form reference foo-input and the form submits to foo.
> You can also do the GET/POST check that Rails suggests and collapse
> everything to just foo. In most cases I just use inline redirect actions
> for cancel buttons and redirect after post and this reduces the clutter
> even more.
>
> 2. I tend to shy away from multiple actions inside classes. For crud I
> use s:action for form preparation (this is actually better because it
> reduces overhead of preparing the form on success). For other types of
> forms, if I have to share logic (rarely) I use a base class, but
> otherwise I just make one class per URL. In most re-use cases I
> introduce re-usable services in a separate tier to clean out actions and
> make the one action per URL simpler to code.
>
> 3. Likewise, I try to avoid heavy re-use of result pages and try to
> stick with the convention based approach. It seems to make the code more
> readable and easy to get into. For CRUD I setup something like this:
>
> ==== Classes ====
> List.java - Fetches the existing entities for display
> Prepare.java - Used only via the s:action and implements Action
> Edit.java - Fetches an existing entity and renders the edit form
> Save.java - Inserts a new entity
> Update.java - Updates the existing entity
> Delete.java - Deletes an entity or entities
>
> ==== Results ====
> add.jsp - Includes form.jsp and passes a parameter to set the action
> type (i.e. save)
> edit.jsp - Includes form.jsp and passes a parameter to set the action
> type (i.e. update)
> form.jsp - The CRUD form used for insert and update
> list.jsp - Lists the current entities
>
> I'm planning on putting up a CRUD demo for SmartURLs at some point, when
> I get time. This will help illustrate what I'm talking about a bit more.
>
> -bp
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org