SmartURLs MailReader Example (was Re: Should I announce SmartURLs or wait?)

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

I have a first run at a Zero Configuratinn,/SmartURLs MailReader under SVN at

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

Everything is checked in, including the JARs (ugh!), and it should be
easy to import as an IDE project.

MailReader Zero uses no XML configuration, other than to set global
options. It does use a lot of annotation, probably too much, but a lot
of that could be resolved via additional conventions.

I'd like this to be an "best practices" application, though I'm not
sure if we yet know what all the best practices :), so comments and
patches are welcome.

I'm hoping to tag a JPA implementation on to this next.

-Ted.

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

Re: SmartURLs MailReader Example (was Re: Should I announce SmartURLs or wait?)

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

On 10/2/07, Brian Pontarelli <br...@pontarelli.com> wrote:
> Finally got a chance to look this over. Here's a few things:

Thanks, Brian. I'm heads-down on something else right now, but I hope
to roll back to the  conventions/annotations stuff soon.

-Ted.

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

Re: SmartURLs MailReader Example (was Re: Should I announce SmartURLs or wait?)

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

> 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).

In the case of Hello, the purpose of the class is to access the
message resources, which are tied to the "actions" package. Of course,
we could change from package.properties to something else, but the
underlying problem is that without a "Hello" class "hello.jsp" isn't
considered part of the "actions" package.

The Login input method that just called super.input wasn't needed
(might have been development cruft). But, @ActionName for login-input
is needed to access message resources (same issue as Hello).


> 2. I tend to shy away from multiple actions inside classes.

In MailReader, both approaches are tried. For Register, there are
RegisterInput and RegisterUpdate classes. For Subscribe, there's one
class with multiple methods.

I'm hard pressed to come up with a technical justification that
supports using one approach over the other. Here, the decision was
driven by whether the validations were easy to share between methods.
(For Register, they are not.)

It seems to be a matter of perspective. One perspective holds that the
Action is a facade for the Model, and Action methods should be
operations on the Model. From the Action/Model perspective it follows
that the usual crud operation should be part of a single class rather
than spread over multiple classes.

Another perspective holds that the Action is a unit of work, or
transaction script. From the Action/Transaction perspective, it
follows that each crud operation should be a separate class, because
each operation is a separate unit of work.

Given a perfect API, I tend to favor the "Action/Transaction" school,
but there are still holes in our validation API which makes sometimes
makes one approach easier than the other.

Even under the transactional approach, we still need to deal with
common notions like "input" and "cancel", and we shouldn't assume that
the ActionSupport versions will always suffice. In the context of
heuristic "convention over configuration", if matching "login-input"
one strategy would be to

 * Look for a LoginInput class
 * Look for a Login class with an input method

Matching methods the same way we match results (only in reverse) would
eliminate most of the @ActionName annotations in MailReader Zero. We
could eleminate the rest by providing a way to associate a message
resources package to actions that fall back to the default
ActionSupport class. (Would it make sense for XWork to be able to
associate a message resource with a namespace?)


> 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.

Feel free to rework the MailReader, including the DAO layer.

We even have use cases :)

 * http://StrutsUniversity.org/MailReader+Use+Cases

and a JPA-compatible set classes available

 * http://svn.apache.org/viewvc/shale/framework/trunk/shale-apps/shale-mailreader-jpa/

-Ted.

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

Re: SmartURLs MailReader Example (was Re: Should I announce SmartURLs or wait?)

[Brian Pontarelli <br...@pontarelli.com>]

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


Ted Husted wrote:
> I have a first run at a Zero Configuratinn,/SmartURLs MailReader under SVN at
>
>  * http://sq1-struts2.googlecode.com/svn/trunk/articles/mailreader-zero/
>
> Everything is checked in, including the JARs (ugh!), and it should be
> easy to import as an IDE project.
>
> MailReader Zero uses no XML configuration, other than to set global
> options. It does use a lot of annotation, probably too much, but a lot
> of that could be resolved via additional conventions.
>
> I'd like this to be an "best practices" application, though I'm not
> sure if we yet know what all the best practices :), so comments and
> patches are welcome.
>
> I'm hoping to tag a JPA implementation on to this next.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>