You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <hu...@apache.org> on 2007/11/20 14:53:37 UTC
Struts 2 CodeBehind/SmartURLs (was Re: Struts 2 Plugin for Grails?)
Basically, we're still trying to identify what merging SmartURLs into
CodeBehind means.
I just backported a SmartURLs application to the Struts 2.x
CodeBehind/Zero-Config.
I wasn't using any Action annotations, so I didn't miss that feature.
Otherwise, I had to
* change the syntax of the Result annotation slightly.
* move my JSP files from under WEB-INF to the application root
I set the extension to "", and it seems to working fine. The only
issue is that I'm trying to redirect to the index action from
index.html, which doesn't seem to work.
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.
* Do we add an ActionName annotation?
* Do we add the extra support for Index pages?
* Do we add the base result page setting, so that pages can be placed
under WEB-INF (or whatever)?
-Ted.
On Nov 20, 2007 8:40 AM, Piero Sartini <li...@pierosartini.de> wrote:
> 1 question - but it is somewhat offtopic:
> I really want to use struts2.1 - but smarturls does work on 2.0 only. I know
> there was some discussion about merging smarturls into the codebehind plugin.
> But as far as I can see there was just a merge of ZeroConfig into CodeBehind.
>
> What is preferred: will smarturls be available for 2.1 or is CodeBehind the
> way to go? (If so, will it be possible to drop in my jars and have their
> actions loaded?)
>
> Thanks,
> Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2 CodeBehind/SmartURLs (was Re: Struts 2 Plugin for Grails?)
Posted by Ted Husted <hu...@apache.org>.
On Nov 21, 2007 5:14 AM, Ted Husted <hu...@apache.org> wrote:
> * Other aspects of the framework might be open to convention-based or
> annotation-based binding too, such as type converters.
I see now that XWork already has annotations for type converters
* http://struts.apache.org/2.x/struts2-core/apidocs/com/opensymphony/xwork2/conversion/annotations/package-frame.html
As well as an interesting set for "embedded" interceptor methods.
* http://struts.apache.org/2.x/struts2-core/apidocs/com/opensymphony/xwork2/interceptor/annotations/package-frame.html
Hmmm.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2 CodeBehind/SmartURLs (was Re: Struts 2 Plugin for Grails?)
Posted by Ted Husted <hu...@apache.org>.
On Nov 20, 2007 7:11 PM, Brian Pontarelli <br...@pontarelli.com> wrote:
> 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.
You might try backporting something to see what you miss. I found that
it was less than I expected :)
> > 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.
I don't know what "cumbersome" means. If there's a bug, could we just
fix it? I also don't know what is meant by SU handling this at the
package, class, and global levels.
> > 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.
>
...
> 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.
Then to what URI does "org.inversoft.vertigo.struts.action" map?
> > 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.
Well, there's external XML configuration for one-time customizations,
and then there's external gluecode that we've been writing to cover
each and every action When we eliminate glue-code, we eliminate
work. But, whether one-time configurations take place in annotation or
external XML is six-of-one, half-a-dozen of the other.
Of course, with package-info.java, we should be able to have a full
complement of both annotation and external configuration options.
But, do we want to support mixing-and-matching both? If we have a full
complement, would it be simpler to expect people to select one
strategy per application? (The way JPA expects us to select one
annotation strategy for columns - field or property.)
> > 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.
One other point that hasn't been mentioned is the SEO conventions. I
haven't tried, but I don't believe the CodeBehind converts camelCase
to seo-case.
A couple of general points:
* Should configuration should follow an order of precedence, such as
Convention, Annotation, and External (XML), where an External
configuration would override any Annotation or Convention. Or, once we
use Annotations, are the External action declarations ignored? (JPA
style.)
* Related question: If we add an ActionName annotation, should it
block the other Convention or External bindings? Or, should it be
added to the list, leaving other bindings intact?
* It would be helpful if annotations were consistently designed to
use smart-defaults and only require us to specify the attributes that
change from the defaults.
* Other aspects of the framework might be open to convention-based or
annotation-based binding too, such as type converters.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2 CodeBehind/SmartURLs (was Re: Struts 2 Plugin for Grails?)
Posted by Brian Pontarelli <br...@pontarelli.com>.
> 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
Re: Struts 2 CodeBehind/SmartURLs (was Re: Struts 2 Plugin for Grails?)
Posted by Don Brown <mr...@twdata.org>.
On 11/20/07, Dave Newton <ne...@yahoo.com> wrote:
> I'd think that package-level annotations should go in
> the package-info.java; that's what it's for, more or
> less.
Perfect! I didn't know about that class, hence my hacky workarounds.
Let's definitely use it.
Don
>
> d.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2 CodeBehind/SmartURLs (was Re: Struts 2 Plugin for Grails?)
Posted by Dave Newton <ne...@yahoo.com>.
--- Don Brown wrote:
> On 11/20/07, Brian Pontarelli wrote:
>> * 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.
I'd prefer having either option available, primarily
because I don't always get to determine the class
hierarchy or class naming conventions.
>> * 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?
I'd think that package-level annotations should go in
the package-info.java; that's what it's for, more or
less.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2 CodeBehind/SmartURLs (was Re: Struts 2 Plugin for Grails?)
Posted by Don Brown <mr...@twdata.org>.
On 11/20/07, Brian Pontarelli <br...@pontarelli.com> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 2 CodeBehind/SmartURLs (was Re: Struts 2 Plugin for Grails?)
Posted by Brian Pontarelli <br...@pontarelli.com>.
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