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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
