On 11/20/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
> 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.
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.
> > * 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).
> > * 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.
>
> > * 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.
> 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.
> * Should we support package level annotations for things like base
> result location, parent package, new result types, interceptors, etc.?
> (I say yes)
How would this work? Would you put the annotation on any class in the
package and it would magically apply for all actions in the package,
like how codebehind works now?
> * 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.
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.
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 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.
Don
>
>
> -bp
>
> ---------------------------------------------------------------------
> 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]
