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 Wed, 21 Nov 2007 00:11:53 GMT

> I prefer type safety wherever possible, but the annotation should
> probably support both for the rresult type.  As for value vs location,
> value is more convenient since you can just do:
>
> @Result("/foo.jsp")
>
> for results that use the default result type, and as mentioned,
> location isn't the param name everywhere.
>   
Okay.


>>>  * Do we add an ActionName annotation?
>>>
>>>       
>> I say yes. I think it adds some controls that could be useful for some
>> folks.
>>     
>
> The codebehind plugin has this in the @Action annotation.  You can
> specify the action name and the namespace for this specific action.
> I'm not really excited about how it is done, however, particularly the
> "package"-level annotations like @ParentPackage, but I'm not sure of a
> good alternative.  Having an annotation on a class that magically
> applies the setting to all actions in that package seems silly to me
> (how it works now).
>   
I thought that this was not really the same. You couldn't map multiple 
actions to a class or handle more different methods for actions. I 
haven't looked at the codebehind in a long time, since I've been using 
SmartURLs for 6 months or so.

>>>  * 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.
>>     
>
> This seems useful, however, I haven't looked at how it is done in
> smarturls.  If it can be done without modifying the action mapper.
> that would be ideal.
>   
It does this right now without action mapping. It adds in the 
appropriate actions and results where necessary to make it work. Very cool.

>>>  * 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.
>>     
>
> Codebehind actually supports this now - struts.codebehind.pathPrefix -
> but I see it isn't documented.
>   
True, but this is global and somewhat cumbersome with respect to slashes 
(just a bug that annoyed me). SU handles this at the package, class and 
global levels.

>> 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)
>>     
>
> I'm not so sure about this one.  Would we do something like stripes
> where we scan for the 'actions' subpackage?  I don't see the
> 'actionPackages' init parameter as too burdensome.
>   
Yeah exactly. This is necessary to allow SU to find actions inside JAR 
files in the classpath without requiring the action package for that JAR 
file to be added to the configuration. Very nice in my opinion to be 
able to drop a JAR file into a project and get a bunch of actions, 
results, etc without any configuration. This is a must for me since 
Vertigo and other projects use it heavily.


>> * 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)
>>     
>
> I'm not sure what you mean by this.
>   
Finding action classes and results from the classpath. For example, 
Vertigo has an action named: Countries in a package named 
org.inversoft.vertigo.struts.action; I map this to the URL 
/vertigo/countries. You can execute this action from a JSP to build a 
list of countries to use with a select box. Very cool. However, I have 
to configure this action package in the struts XML or properties file or 
use the current component.xml solution to inform SU that this package 
exists. I think it would be better to just find all actions in packages 
with specific names (like Stripes). That way I don't have any configuration.

> I should also add, I don't see XML going away nor do I want it to.
> There will always be more things you can do in XML that you won't be
> able to do in annotations, and I see the codebehind plugin accepting
> this fact.  I'd like it to add conventions and a few annotations to
> cover 90-95% of the cases, leaving more involved things like defining
> results, interceptors, and more complex package-level config to XML.
>   
I'm on the other side of the fence. None of my apps to date have used 
any XML at all. I prefer it this way and only use XML when I absolutely 
have to.

> Also, if I haven't mentioned it already, Struts 2.1 supports multiple
> filter instances in a webapp.  This means you could have two filters,
> each looking for actions in a different root package and using
> different path prefixes for their results.  I'm still not clear why
> you would be putting templates in two different root directories, but
> if you wanted to, you can.
>   
This would be overkill with SU because you can handle multiple action 
packages, multiple result locations, and most configuration with a 
single filter. Obviously this might be helpful for some situations, but 
I haven't found a need for it yet.

> This is a great first step towards integrating the two plugins.
> Perhaps the next step, after some more discussion, would be to set up
> a matrix of the features SmartURLs has that codebehind doesn't, then
> we can systematically evaluate them in a way that is easy to follow
> and record.
>   
I can put this together, but I'd like to finalize some decisions around 
this stuff pretty soon. I think it is really just a matter of these last 
3-5 items and then just integration.

-bp

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


Mime
View raw message