Struts 3 and namespaces

[Paul Benedict <pb...@apache.org>]

One concept I never really liked in S2 are namespaces. I never found a good
reason to logically group actions together with common interceptor setup.
Rather I always find myself in the situation where the interceptor stack is
globally set and actions have one-off changes. And I also never liked how
namespaces limit the scope of result types.

Am I right or is this feature really valuable?

Re: Struts 3 and namespaces

[Paul Benedict <pb...@apache.org>]

Ken,

I am in agreement interceptor stacks should be something like templates. I
think we need to do something that's a mix of JSF and S1. JSF has a
predefined lifecycle and S1 had named commands (its version of
interceptors). So if you want to inject something before or after a step in
the lifecycle, it needs to be named. Many times, for example, I just wanted
to replace one part of the interceptor stack without creating a new
interceptor stack. That's the kind of functionality I am desiring.



Cheers,
Paul

On Tue, Dec 9, 2014 at 4:19 PM, Ken McWilliams <ke...@gmail.com>
wrote:
>
> Interceptor stacks don't translate well with annotations (the struts2
> package-name and action-name are required by the action-mapper to kick off
> the processing, two keys are a pretty minimal requirement). It only makes
> sense to use Struts2 package annotations as Java package-level annotations.
> But then if the annotations were used that way (which as far as I know they
> are not), you would get the worst of both worlds. You would have
> annotations but they would not be on the action so you would need to look
> elsewhere but unlike struts.xml it would be split-up into different files
> (package-info.java) but where struts.xml will explicitly state what other
> files are involved in the config you would have to hunt and peck for the
> package meta-data.
>
> At the end of the day, for interceptor definition struts.xml is the most
> ideal. If annotations are being used conventions are probably at play, and
> annotations should then be used for what they are intended for: overriding
> the conventions, and in general shouldn't be something you do on every
> action, otherwise the default conventions behaviour should be altered for
> your case.
>
> There of course is room for improvement, perhaps considering
> interceptor-stacks something like templates? That is parts of templates can
> be changed out, without needing a full redefinition.
>
> On Tue, Dec 9, 2014 at 2:14 PM, Paul Benedict <pb...@apache.org>
> wrote:
>
> > I hear your points.
> >
> > In addition, I noticed that namespaces don't translate well with
> > annotations. It might just be more consistent to configure on a per
> action
> > basis just by specifying the interceptor stack to use.
> >
> > Also, I find namespaces most frustrating when I rename URLs and have to
> > move around the config to put the XML action configs in the right
> > namespaces.
> > On Dec 9, 2014 2:57 PM, "Dave Newton" <da...@gmail.com> wrote:
> >
> > > I used package-level interceptors from time to time, mostly for really
> > easy
> > > auth interceptors applied to chunks of pages. There was some other
> > use-case
> > > I had, but I can't recall what it was; it was related to some data
> > > transformations.
> > >
> > > It also provides a mechanism for grouping actions together in a logical
> > way
> > > w/o having to rely on consistent URL naming convention that can be
> > > fat-fingered pretty easily, but I'm not sure that counts as "really
> > > valuable".
> > >
> > > On Tue, Dec 9, 2014 at 3:52 PM, Paul Benedict <pb...@apache.org>
> > > wrote:
> > >
> > > > One concept I never really liked in S2 are namespaces. I never found
> a
> > > good
> > > > reason to logically group actions together with common interceptor
> > setup.
> > > > Rather I always find myself in the situation where the interceptor
> > stack
> > > is
> > > > globally set and actions have one-off changes. And I also never liked
> > how
> > > > namespaces limit the scope of result types.
> > > >
> > > > Am I right or is this feature really valuable?
> > > >
> > >
> > >
> > >
> > > --
> > > e: davelnewton@gmail.com
> > > m: 908-380-8699
> > > s: davelnewton_skype
> > > t: @dave_newton <https://twitter.com/dave_newton>
> > > b: Bucky Bits <http://buckybits.blogspot.com/>
> > > g: davelnewton <https://github.com/davelnewton>
> > > so: Dave Newton <http://stackoverflow.com/users/438992/dave-newton>
> > >
> >
>

Re: Struts 3 and namespaces

[Ken McWilliams <ke...@gmail.com>]

Interceptor stacks don't translate well with annotations (the struts2
package-name and action-name are required by the action-mapper to kick off
the processing, two keys are a pretty minimal requirement). It only makes
sense to use Struts2 package annotations as Java package-level annotations.
But then if the annotations were used that way (which as far as I know they
are not), you would get the worst of both worlds. You would have
annotations but they would not be on the action so you would need to look
elsewhere but unlike struts.xml it would be split-up into different files
(package-info.java) but where struts.xml will explicitly state what other
files are involved in the config you would have to hunt and peck for the
package meta-data.

At the end of the day, for interceptor definition struts.xml is the most
ideal. If annotations are being used conventions are probably at play, and
annotations should then be used for what they are intended for: overriding
the conventions, and in general shouldn't be something you do on every
action, otherwise the default conventions behaviour should be altered for
your case.

There of course is room for improvement, perhaps considering
interceptor-stacks something like templates? That is parts of templates can
be changed out, without needing a full redefinition.

On Tue, Dec 9, 2014 at 2:14 PM, Paul Benedict <pb...@apache.org> wrote:

> I hear your points.
>
> In addition, I noticed that namespaces don't translate well with
> annotations. It might just be more consistent to configure on a per action
> basis just by specifying the interceptor stack to use.
>
> Also, I find namespaces most frustrating when I rename URLs and have to
> move around the config to put the XML action configs in the right
> namespaces.
> On Dec 9, 2014 2:57 PM, "Dave Newton" <da...@gmail.com> wrote:
>
> > I used package-level interceptors from time to time, mostly for really
> easy
> > auth interceptors applied to chunks of pages. There was some other
> use-case
> > I had, but I can't recall what it was; it was related to some data
> > transformations.
> >
> > It also provides a mechanism for grouping actions together in a logical
> way
> > w/o having to rely on consistent URL naming convention that can be
> > fat-fingered pretty easily, but I'm not sure that counts as "really
> > valuable".
> >
> > On Tue, Dec 9, 2014 at 3:52 PM, Paul Benedict <pb...@apache.org>
> > wrote:
> >
> > > One concept I never really liked in S2 are namespaces. I never found a
> > good
> > > reason to logically group actions together with common interceptor
> setup.
> > > Rather I always find myself in the situation where the interceptor
> stack
> > is
> > > globally set and actions have one-off changes. And I also never liked
> how
> > > namespaces limit the scope of result types.
> > >
> > > Am I right or is this feature really valuable?
> > >
> >
> >
> >
> > --
> > e: davelnewton@gmail.com
> > m: 908-380-8699
> > s: davelnewton_skype
> > t: @dave_newton <https://twitter.com/dave_newton>
> > b: Bucky Bits <http://buckybits.blogspot.com/>
> > g: davelnewton <https://github.com/davelnewton>
> > so: Dave Newton <http://stackoverflow.com/users/438992/dave-newton>
> >
>

Re: Struts 3 and namespaces

[Paul Benedict <pb...@apache.org>]

I hear your points.

In addition, I noticed that namespaces don't translate well with
annotations. It might just be more consistent to configure on a per action
basis just by specifying the interceptor stack to use.

Also, I find namespaces most frustrating when I rename URLs and have to
move around the config to put the XML action configs in the right
namespaces.
On Dec 9, 2014 2:57 PM, "Dave Newton" <da...@gmail.com> wrote:

> I used package-level interceptors from time to time, mostly for really easy
> auth interceptors applied to chunks of pages. There was some other use-case
> I had, but I can't recall what it was; it was related to some data
> transformations.
>
> It also provides a mechanism for grouping actions together in a logical way
> w/o having to rely on consistent URL naming convention that can be
> fat-fingered pretty easily, but I'm not sure that counts as "really
> valuable".
>
> On Tue, Dec 9, 2014 at 3:52 PM, Paul Benedict <pb...@apache.org>
> wrote:
>
> > One concept I never really liked in S2 are namespaces. I never found a
> good
> > reason to logically group actions together with common interceptor setup.
> > Rather I always find myself in the situation where the interceptor stack
> is
> > globally set and actions have one-off changes. And I also never liked how
> > namespaces limit the scope of result types.
> >
> > Am I right or is this feature really valuable?
> >
>
>
>
> --
> e: davelnewton@gmail.com
> m: 908-380-8699
> s: davelnewton_skype
> t: @dave_newton <https://twitter.com/dave_newton>
> b: Bucky Bits <http://buckybits.blogspot.com/>
> g: davelnewton <https://github.com/davelnewton>
> so: Dave Newton <http://stackoverflow.com/users/438992/dave-newton>
>

Re: Struts 3 and namespaces

[Dave Newton <da...@gmail.com>]

I used package-level interceptors from time to time, mostly for really easy
auth interceptors applied to chunks of pages. There was some other use-case
I had, but I can't recall what it was; it was related to some data
transformations.

It also provides a mechanism for grouping actions together in a logical way
w/o having to rely on consistent URL naming convention that can be
fat-fingered pretty easily, but I'm not sure that counts as "really
valuable".

On Tue, Dec 9, 2014 at 3:52 PM, Paul Benedict <pb...@apache.org> wrote:

> One concept I never really liked in S2 are namespaces. I never found a good
> reason to logically group actions together with common interceptor setup.
> Rather I always find myself in the situation where the interceptor stack is
> globally set and actions have one-off changes. And I also never liked how
> namespaces limit the scope of result types.
>
> Am I right or is this feature really valuable?
>



-- 
e: davelnewton@gmail.com
m: 908-380-8699
s: davelnewton_skype
t: @dave_newton <https://twitter.com/dave_newton>
b: Bucky Bits <http://buckybits.blogspot.com/>
g: davelnewton <https://github.com/davelnewton>
so: Dave Newton <http://stackoverflow.com/users/438992/dave-newton>

Re: Struts 3 and namespaces

[Lukasz Lenart <lu...@apache.org>]

Hi,

I don't think throwing away the namespaces logic is a good idea - if
we do it, all the users will have to migrate in almost the same manner
as from S1 to S2. For most of them it will be a real pain so because
of that I'm against that.

There is already "slashes in action names" mechanism which should be
extended to match your needs or maybe we should introduce something
other/better.

Another thing is that the usage of annotations should be treated as
exception (someone already said that) - if you clutter your actions
with the annotations it's obvious smell that something went wrong. The
annotations are there to allow narrow config/flow to your specific use
case where convention doesn't fit well.

And I like logical grouping of actions in the same namespace and if
you see some weaknesses we must improve how namespaces work not
throwing them away.

I don't have any real use cases now as I don't use S2 on daily basis
so if any of the aboves is a mistake please let me know :)

I don't get the problem with interceptors, what's wrong with defining
few stacks and use them across different namespaces?


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

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

Re: Struts 3 and namespaces

[Paul Benedict <pb...@apache.org>]

Thanks for the responses. I appreciate knowing how namespaces are used.

So it sounds to me (correct me if wrong) that namespaces provided two
purposes: (1) a convenient way of chopping off the first part of the URI
and (2) namespace level interceptor. I think that's pretty minimal
functionality. Without namespaces, you would just add the first part of the
URI back to your actions and link to a globally defined interceptor stack.
Is it all that different?


Cheers,
Paul

On Fri, Dec 12, 2014 at 5:46 AM, Kofford, C. Todd <tk...@ku.edu> wrote:
>
> We use namespaces when we have an application that runs both as a portlet
> & as a standalone web application. In the former case the portlet
> interceptor sits at the top of the stack & the latter is just our standard
> interceptor stack, and we use namespaces to differentiate action
> invocations between the 2 types.
>
> Maybe there's a better way to accomplish this, but it's just the way we've
> always done things. If this were to change, we would have work to do.
>
> --
> Todd Kofford
> tkofford@ku.edu
>
>
> > On Dec 12, 2014, at 1:54 AM, rgm <rg...@rgm.nu> wrote:
> >
> > To me it's valuable for keeping an interceptor stack separate for api
> > requests.
> >
> > /api/v1/people/list
> > Json result
> >
> > Vs
> >
> > /listpeople.action
> > Web / template result
> >> On Dec 9, 2014 2:52 PM, "Paul Benedict" <pb...@apache.org> wrote:
> >>
> >> One concept I never really liked in S2 are namespaces. I never found a
> good
> >> reason to logically group actions together with common interceptor
> setup.
> >> Rather I always find myself in the situation where the interceptor
> stack is
> >> globally set and actions have one-off changes. And I also never liked
> how
> >> namespaces limit the scope of result types.
> >>
> >> Am I right or is this feature really valuable?
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Re: Struts 3 and namespaces

["Kofford, C. Todd" <tk...@ku.edu>]

We use namespaces when we have an application that runs both as a portlet & as a standalone web application. In the former case the portlet interceptor sits at the top of the stack & the latter is just our standard interceptor stack, and we use namespaces to differentiate action invocations between the 2 types.

Maybe there's a better way to accomplish this, but it's just the way we've always done things. If this were to change, we would have work to do.

--
Todd Kofford
tkofford@ku.edu


> On Dec 12, 2014, at 1:54 AM, rgm <rg...@rgm.nu> wrote:
> 
> To me it's valuable for keeping an interceptor stack separate for api
> requests.
> 
> /api/v1/people/list
> Json result
> 
> Vs
> 
> /listpeople.action
> Web / template result
>> On Dec 9, 2014 2:52 PM, "Paul Benedict" <pb...@apache.org> wrote:
>> 
>> One concept I never really liked in S2 are namespaces. I never found a good
>> reason to logically group actions together with common interceptor setup.
>> Rather I always find myself in the situation where the interceptor stack is
>> globally set and actions have one-off changes. And I also never liked how
>> namespaces limit the scope of result types.
>> 
>> Am I right or is this feature really valuable?
>> 

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

Re: Struts 3 and namespaces

[rgm <rg...@rgm.nu>]

To me it's valuable for keeping an interceptor stack separate for api
requests.

/api/v1/people/list
Json result

Vs

/listpeople.action
Web / template result
On Dec 9, 2014 2:52 PM, "Paul Benedict" <pb...@apache.org> wrote:

> One concept I never really liked in S2 are namespaces. I never found a good
> reason to logically group actions together with common interceptor setup.
> Rather I always find myself in the situation where the interceptor stack is
> globally set and actions have one-off changes. And I also never liked how
> namespaces limit the scope of result types.
>
> Am I right or is this feature really valuable?
>