Instead of returning a Result object, we can also consider calling out to a
result method. This is how Rails works. For example:
class FooAction ... {
Foo foo = new Foo(); // populated from request parameters.
public void create() {
if (foo.isValid())
redirectTo("ListFoos");
else
chainTo("NewFoo");
}
...
}
These methods could be inherited from a base class, statically imported, or
something else.
If you like annotations, we should also consider abstract methods which
could be implemented by Struts at run time:
class FooAction ... {
Foo foo = new Foo(); // populated from request parameters.
public void create() {
if (foo.isValid())
listFoos();
else
newFoo();
}
@Redirect("ListFoos")
abstract void listFoos();
@Chain("NewFoo")
abstract void newFoo();
...
}
This doesn't require inheritance and it's still easy to unit test with
EasyMock.
Bob
On 7/25/06, Don Brown <[EMAIL PROTECTED]> wrote:
Tim Fennell wrote:
> I was going to chime in on this, so I may as well now. Stripes, through
> it's default way of routing events, will allow a submitted form or URL
> to invoke any method that is public no-arg and returns a Resolution -
> this seems much safer because Resolution is a Stripes specific class as
> opposed to String, which obviously isn't. In this case @HandlesEvent is
> only used to mark methods that have different return types, or need to
> be aliased.
I personally would like to see XWork enhanced to support action methods
returning Result instances directly, however we would have to thoroughly
think
through the consequences.
Reasons for:
- Better security
- Easier, more explicit
- Results will probably be defined as annotations soon, so why not just
return
the Result directly?
- Allows non-annotation apps to drastically minimize config
- Supports more complex results
Reasons against:
- The Action interface really loses most of its meaning
- ActionSupport could no longer extend Action
- XWork internals would need modification since many places expect a
result code
- Supporting the return of Result, String, and Object might be confusing
for
new developers
- Current Results would need some improvements to make them easier to
use
(better constructors, default location names/patterns, etc)
Again, all things considered, I'd really like to see us add the ability to
return Results directly as I think it just makes things easier. The
ability to
separate JSP paths from Java code, IMO, is way overrated and years of its
practice hasn't shown the additional complexity is really worth it. For
those
that prefer the old style, they would still have that option.
Don
>
> -t
>
> On Jul 25, 2006, at 4:11 PM, Ted Husted wrote:
>
>> On 7/25/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
>>> @Action to mark it as an Action method?
>>
>> Stripes uses the annontation @DefaultHandler where we would configure
>> a default action, which might imply the annotation @Handler for what
>> we are talking about here.
>>
>> *
http://stripes.mc4j.org/confluence/display/stripes/Annotation+Reference
>>
>> -Ted.
>>
>> ---------------------------------------------------------------------
>> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
