struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <br...@pontarelli.com>
Subject Re: Struts 2 CodeBehind/SmartURLs (was Re: Struts 2 Plugin for Grails?)
Date Tue, 20 Nov 2007 16:36:05 GMT
Here are my thoughts:
> AFAICT, the questions then become
>
>  * Which Result annotation syntax to support?
>
>    ** CB uses a .class reference, SU uses a string setting that
> corresponds to the Result name.
>   ** CB uses "value" where SU uses location.
>   
SU because it provides more flexibility with respect to action names, 
mappings, etc. I could go either way with the result type String vs. 
Class. I tend to prefer remaining close to the XML whenever possible. I 
feel the same about the value vs. location naming. Again, the XML uses 
location since that this the DEFAULT_PARAM for most result types, so I 
prefer that.

>  * Do we add an ActionName annotation?
>   
I say yes. I think it adds some controls that could be useful for some 
folks.

>  * Do we add the extra support for Index pages?
>   
I say yes because this is one of my favorite features and I use this 
heavily.

>  * Do we add the base result page setting, so that pages can be placed
> under WEB-INF (or whatever)?
>   
I say yes. It protects those resources that shouldn't be accessible 
directly by clients.

There are a few others things to consider:

* Should we leverage the action.packages configuration or a naming 
convention for finding action packages?
    (I prefer convention)

* Should we support package level annotations for things like base 
result location, parent package, new result types, interceptors, etc.?
    (I say yes)

* If we leverage the action.packages configuration, how do we support 
actions and results inside the classpath?
    (Right now it is component.xml, which is not ideal. This is my main 
reason for convention over configuration for finding action packages)


-bp

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


Mime
View raw message