I really like the work they have done on the Convention plugin. This
is a comprehensive set of configuration annotations that replaces
CodeBehind/ZeroConfig. It is still in the sandbox I think, although I
haven't checked in a little while. Something I really like about it
is the @Action annotation you can put on methods. Very sweet. But in
the end, whether it is because I am just used to a certain way or one
is harder than other, I still use XML when I am in get things done
mode. I have theories and opinions about the whole XML-based
configuration hoohah, but I can post that on the Rails forum.
Check out the Convention plugin at:
http://cwiki.apache.org/S2PLUGINS/convention-plugin.html
Another very cool plugin is the REST plugin:
http://struts.apache.org/2.x/docs/rest-plugin.html
The REST Plugin requires Struts 2.1.1 or higher and can be difficult
until you get used to it. If you already design your actions in the
zesty resty way, then the plugin will cut out alot of configuration.
Another complication is that REST uses CodeBehind. Theoretically, if
you were to get the HEAD trunk source, you would pick up Musachy's
commits that lets REST use Convention instead. These plugins work
well but they are technically work in progress.....Annotations and
even no config are definitely the future for Struts2. I say go for
annotations and if you can use pre-release code, use Convention.
On Aug 8, 2008, at 8:15 AM, Martin Homik wrote:
Matt, this is not what I meant. I asked whether it is preferable to
use
1. @Result annotations as a replacement for result declarations in
struts.xml
2. @Validation/@Required* annotations as a replacement for *-
validation.xml
files
The idea is to get rid of xml as much as possible without loosing
expressivity
As far as I can see, the annotation approach has two problems:
1) lacks the ability of name aliasing, hence actions cannot be mapped
to methods other than execute(), and
2) the ability of defining validation visitors
But I might be wrong. :-)
Cheers,
Martin
mraible wrote:
AppFuse is configured by default to use Zero Configuration, which
means you don't have to use XML or annotations. Just name your
classes
XXXAction and put them in the package defined in your web.xml.
Matt
On Fri, Aug 8, 2008 at 2:44 AM, Martin Homik <[EMAIL PROTECTED]> wrote:
Dear all,
I'd like to ask the community whether you have any experience with
AppFuse
and Struts2 annotations.
The AppFuse tutorial introduces only the xml-based declarative
architecture.
Also, in the book "Struts2 in Action" the authors use the xml-based
approach
for educational reasons, but they expect developers to use
annotations.
They
say: "... Struts2 developers are ardently moving toward a
zero-configuration
system that uses convention over configuration, with annotations
serving
as
an elegant override mechanism when conventions aren't followed."
What do you think? Should one favour annotations over xml files? Has
Struts2
matured for using annotations? Personally, I'd like to give it a
shot. A
similar experience with AppFuse which I valued pretty much was
using JPA
annotations instead of writing Hibernate xml files.
Cheers,
Martin
--
View this message in context:
http://www.nabble.com/Experience-with-Struts2-Annotations--tp18888046s2369p18888046.html
Sent from the AppFuse - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
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]
--
View this message in context:
http://www.nabble.com/Experience-with-Struts2-Annotations--tp18888046s2369p18893766.html
Sent from the AppFuse - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
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]
