You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by tom_brokaw <er...@bbh.com> on 2008/02/20 17:02:47 UTC

Actions without extending ActionSupport?

Hi,

I was under the impression that I could write actions without extending
ActionSupport or implementing any struts2/xwork interfaces. However, I
cannot figure out how to add action errors (ActionSupport.addActionError())
to an action if not extending ActionSupport. I looked at
ActionContext.getContext() and ServletActionContext, but don't see a way to
add action errors.

Anyone know how to do this?

Thank you in advance for any suggestions.
-- 
View this message in context: http://www.nabble.com/Actions-without-extending-ActionSupport--tp15591064p15591064.html
Sent from the Struts - User mailing list archive at Nabble.com.


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


Re: [OT] Re: Actions without extending ActionSupport?

Posted by st...@gmail.com.
Thanks bro.  I'll hit it after I make a QDoba run.

On Fri, Feb 29, 2008 at 11:57 AM, Dave Newton <ne...@yahoo.com> wrote:

> --- stanlick@gmail.com wrote:
> > How many "more" times do you want to answer
> > the POJO/ActionSupport question?
>
> A million; how could I possibly get tired of such fun?
>
> > Would you be willing to help me seed it with your top ten
> > puzzlers from this list?
>
> Sounds pretty cool--I'd put out a general call for FAQ-oriented stuff
> (heck,
> some of the FAQ entries from the wiki probably qualify, like "how do I
> access
> the request in my action?" and the like).
>
> Off the top of my head I'd include (most of which you probably already
> have):
>
> - Access to the HTTP stuff.
> - Can it really be a POJO?
> - Why does my form keep emitting table elements?
> - I added an <interceptor-ref.../> to my action's XML config and now
> nothing works.
> - Single-quoted, single-char in OGNL is a char, not string.
> - Something about the <s:url.../> params incluson/exclusion.
>
> That's all I can think of at the moment without doing some list analysis
> or
> checking the wiki.
>
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


-- 
Scott
stanlick@gmail.com

Re: [OT] Re: Actions without extending ActionSupport?

Posted by Clown Boots <cl...@gmail.com>.

newton.dave wrote:
> Ah, I get it now. How many email addresses do you have, anyway?

My arguments stand whether or not I use the same email address. I don't like
registrations so I try to use bugmenot.com for things like that. The name
attached to my post has nothing to do with the legitimacy of my statements,
and I hope we can continue this dialog. I am not trying to waste your time
or "troll you". I am trying to engage meaning debate with the purpose of
(hopefully) improving Struts2.


stanlick wrote:
> I have recently finished writing a nifty little S2/Db4o web application
> that allows for quiz taking on your favorite subjects

Are you hijacking this thread with your topic? I don't see the relevance.
-- 
View this message in context: http://www.nabble.com/Actions-without-extending-ActionSupport--tp15591064p15764476.html
Sent from the Struts - User mailing list archive at Nabble.com.


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


Re: [OT] Re: Actions without extending ActionSupport?

Posted by Dave Newton <ne...@yahoo.com>.
--- stanlick@gmail.com wrote:
> How many "more" times do you want to answer 
> the POJO/ActionSupport question?

A million; how could I possibly get tired of such fun?

> Would you be willing to help me seed it with your top ten
> puzzlers from this list?

Sounds pretty cool--I'd put out a general call for FAQ-oriented stuff (heck,
some of the FAQ entries from the wiki probably qualify, like "how do I access
the request in my action?" and the like). 

Off the top of my head I'd include (most of which you probably already have):

- Access to the HTTP stuff.
- Can it really be a POJO?
- Why does my form keep emitting table elements?
- I added an &lt;interceptor-ref.../&gt; to my action's XML config and now
nothing works.
- Single-quoted, single-char in OGNL is a char, not string.
- Something about the &lt;s:url.../&gt; params incluson/exclusion.

That's all I can think of at the moment without doing some list analysis or
checking the wiki.

Dave


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


Re: [OT] Re: Actions without extending ActionSupport?

Posted by st...@gmail.com.
Hey Dave --

How many "more" times do you want to answer the POJO/ActionSupport
question?  I have recently finished writing a nifty little S2/Db4o web
application that allows for quiz taking on your favorite subjects.  It
randomizes questions, maintains global statistics [so you can quickly see
how you rank against everyone else] and will soon have support for tutoring
the user on questions missed.  I have seen many quiz apps that will
calculate correct/missed totals and then kick you out the door, but this one
is different.  Would you be willing to help me seed it with your top ten
puzzlers from this list?  I will have it hosted with several sample
questions this afternoon but I would ultimately like to load it up for
developers who want to learn the Struts 2 framework and have fun doing it!

Scott

On Fri, Feb 29, 2008 at 10:47 AM, Dave Newton <ne...@yahoo.com> wrote:

> Ah, I get it now. How many email addresses do you have, anyway?
>
> I'm definitely too easy to troll.
>
> --- nobody <da...@budweiser.com> wrote:
>
> >
> >
> > Dave Newton wrote:
> > > in some ways I like being coupled to static methods even less because
> > it's
> > > not injectable.
> >
> > Not true. FacesContext is injectable with if you use Seam, Spring IoC,
> or
> > Guice. Perhaps the native IoC container in JSF will provide this
> > injectability natively in JSF 2.0.
> >
> >
> > Jeromy Evans - Blue Sky Minds wrote:
> > > Agreed. Using a static method call is NOT a form of decoupling from
> the
> > > framework. In fact, it's less desirable than an interface because its
> > > harder to
> > > test and override.
> >
> > They are degrees of coupling. JSF's sue of a static method call results
> in
> > much less framework coupling than, say, inheriting a base class as
> Struts2
> > would have you do. This is because the static method call can be mocked
> > quite easily whereas Struts2 base classes (and whatever they depend on)
> not
> > nearly as easily.
> >
> > I agree that the ultimate decoupling is simple interfaces, and this is
> > precisely what JSF and Spring-MVC use. Both also use static method calls
> to
> > obtain framework services. Struts2 does not. Instead, Struts2 forces you
> to
> > either use its base classes or, if you choose to use its interfaces,
> > rewrite
> > a lot of plumbing that you shouldn't have to rewrite.
> >
> > As has been pointed out in other threads, suffers from the Fragile Base
> > Class anti-pattern (http://en.wikipedia.org/wiki/Fragile_base_class). I
> > don't think anyone would claim JSF and Spring-MVC suffer from this
> problem,
> > and although they do have problems of their own, they're not necessarily
> > fundamental design issues like with Struts2.
> >
> > --
> > View this message in context:
> >
>
> http://www.nabble.com/Actions-without-extending-ActionSupport--tp15591064p15762345.html
> > Sent from the Struts - User mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


-- 
Scott
stanlick@gmail.com

Re: [OT] Re: Actions without extending ActionSupport?

Posted by nobody <da...@budweiser.com>.

newton.dave wrote:
> 
> Ah, I get it now. How many email addresses do you have, anyway?
> 
> I'm definitely too easy to troll.
> 

I am very sorry I was rude and used a BugMeNot user on Nabble to continue to
spam the struts-user mailing list. It shows a lack of class and I will stop
using this and other anonymous users and will be a man from now on.

Oh, snap.
-- 
View this message in context: http://www.nabble.com/Actions-without-extending-ActionSupport--tp15591064p15762889.html
Sent from the Struts - User mailing list archive at Nabble.com.


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


[OT] Re: Actions without extending ActionSupport?

Posted by Dave Newton <ne...@yahoo.com>.
Ah, I get it now. How many email addresses do you have, anyway?

I'm definitely too easy to troll.

--- nobody <da...@budweiser.com> wrote:

> 
> 
> Dave Newton wrote:
> > in some ways I like being coupled to static methods even less because
> it's
> > not injectable.
> 
> Not true. FacesContext is injectable with if you use Seam, Spring IoC, or
> Guice. Perhaps the native IoC container in JSF will provide this
> injectability natively in JSF 2.0.
> 
> 
> Jeromy Evans - Blue Sky Minds wrote:
> > Agreed. Using a static method call is NOT a form of decoupling from the
> > framework. In fact, it's less desirable than an interface because its
> > harder to 
> > test and override.
> 
> They are degrees of coupling. JSF's sue of a static method call results in
> much less framework coupling than, say, inheriting a base class as Struts2
> would have you do. This is because the static method call can be mocked
> quite easily whereas Struts2 base classes (and whatever they depend on) not
> nearly as easily. 
> 
> I agree that the ultimate decoupling is simple interfaces, and this is
> precisely what JSF and Spring-MVC use. Both also use static method calls to
> obtain framework services. Struts2 does not. Instead, Struts2 forces you to
> either use its base classes or, if you choose to use its interfaces,
> rewrite
> a lot of plumbing that you shouldn't have to rewrite.
> 
> As has been pointed out in other threads, suffers from the Fragile Base
> Class anti-pattern (http://en.wikipedia.org/wiki/Fragile_base_class). I
> don't think anyone would claim JSF and Spring-MVC suffer from this problem,
> and although they do have problems of their own, they're not necessarily
> fundamental design issues like with Struts2.
> 
> -- 
> View this message in context:
>
http://www.nabble.com/Actions-without-extending-ActionSupport--tp15591064p15762345.html
> Sent from the Struts - User mailing list archive at Nabble.com.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 


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


Re: Actions without extending ActionSupport?

Posted by st...@gmail.com.
Hey "nobody" dude --

If S2 is not for you, why do you spend so much time here?

On Fri, Feb 29, 2008 at 10:37 AM, nobody <da...@budweiser.com> wrote:

>
>
> Dave Newton wrote:
> > in some ways I like being coupled to static methods even less because
> it's
> > not injectable.
>
> Not true. FacesContext is injectable with if you use Seam, Spring IoC, or
> Guice. Perhaps the native IoC container in JSF will provide this
> injectability natively in JSF 2.0.
>
>
> Jeromy Evans - Blue Sky Minds wrote:
> > Agreed. Using a static method call is NOT a form of decoupling from the
> > framework. In fact, it's less desirable than an interface because its
> > harder to
> > test and override.
>
> They are degrees of coupling. JSF's sue of a static method call results in
> much less framework coupling than, say, inheriting a base class as Struts2
> would have you do. This is because the static method call can be mocked
> quite easily whereas Struts2 base classes (and whatever they depend on)
> not
> nearly as easily.
>
> I agree that the ultimate decoupling is simple interfaces, and this is
> precisely what JSF and Spring-MVC use. Both also use static method calls
> to
> obtain framework services. Struts2 does not. Instead, Struts2 forces you
> to
> either use its base classes or, if you choose to use its interfaces,
> rewrite
> a lot of plumbing that you shouldn't have to rewrite.
>
> As has been pointed out in other threads, suffers from the Fragile Base
> Class anti-pattern (http://en.wikipedia.org/wiki/Fragile_base_class). I
> don't think anyone would claim JSF and Spring-MVC suffer from this
> problem,
> and although they do have problems of their own, they're not necessarily
> fundamental design issues like with Struts2.
>
> --
> View this message in context:
> http://www.nabble.com/Actions-without-extending-ActionSupport--tp15591064p15762345.html
> Sent from the Struts - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


-- 
Scott
stanlick@gmail.com

Re: Actions without extending ActionSupport?

Posted by nobody <da...@budweiser.com>.

Dave Newton wrote:
> in some ways I like being coupled to static methods even less because it's
> not injectable.

Not true. FacesContext is injectable with if you use Seam, Spring IoC, or
Guice. Perhaps the native IoC container in JSF will provide this
injectability natively in JSF 2.0.


Jeromy Evans - Blue Sky Minds wrote:
> Agreed. Using a static method call is NOT a form of decoupling from the
> framework. In fact, it's less desirable than an interface because its
> harder to 
> test and override.

They are degrees of coupling. JSF's sue of a static method call results in
much less framework coupling than, say, inheriting a base class as Struts2
would have you do. This is because the static method call can be mocked
quite easily whereas Struts2 base classes (and whatever they depend on) not
nearly as easily. 

I agree that the ultimate decoupling is simple interfaces, and this is
precisely what JSF and Spring-MVC use. Both also use static method calls to
obtain framework services. Struts2 does not. Instead, Struts2 forces you to
either use its base classes or, if you choose to use its interfaces, rewrite
a lot of plumbing that you shouldn't have to rewrite.

As has been pointed out in other threads, suffers from the Fragile Base
Class anti-pattern (http://en.wikipedia.org/wiki/Fragile_base_class). I
don't think anyone would claim JSF and Spring-MVC suffer from this problem,
and although they do have problems of their own, they're not necessarily
fundamental design issues like with Struts2.

-- 
View this message in context: http://www.nabble.com/Actions-without-extending-ActionSupport--tp15591064p15762345.html
Sent from the Struts - User mailing list archive at Nabble.com.


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


Re: Actions without extending ActionSupport?

Posted by Jeromy Evans <je...@blueskyminds.com.au>.
Dave Newton wrote:
> --- eric.jung@bbh.com wrote:
>   
>> public class MyAction {
>>   public String deleteUser() {
>>     // Here I can inject errors for display on the JSP by writing:
>>     FacesContext.getCurrentInstance().addMessage("userNameField", "Sorry, 
>> that username is unknown");
>>     return "input";
>>   }
>> }
>>
>> Notice MyAction inherits no JSF-specific interfaces and extends no 
>> JSF-specific classes, which is I find very desirable.
>>     
>
> Well... Obviously code-coupling is bad. You're still coupled to the
> FacesContext, though, and in some ways I like being coupled to static methods
> even less because it's not injectable.
>
>   

Agreed. Using a static method call is NOT a form of decoupling from the 
framework.
In fact, it's less desirable than an interface because its harder to 
test and override.

>> Just wondering if struts2 has a way to decouple actions in this manner. 
>>     
>
>   
Either:
  Implementing ValidationAware and delegating to the 
ValidationAwareSupport mixin is best;
or if you really desire an equivalent static call:
 - add a ValidationAware instance to the ActionContext via a custom 
Interceptor; and
 - ((ValidationAware) 
ActionContext.getActionContext().get("myValidation")).addActionError("");
may work.
ie. the context contains a ValidationAware object rather than your 
action being the ValidationAware object.

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


Re: Actions without extending ActionSupport?

Posted by Dave Newton <ne...@yahoo.com>.
--- eric.jung@bbh.com wrote:
> public class MyAction {
>   public String deleteUser() {
>     // Here I can inject errors for display on the JSP by writing:
>     FacesContext.getCurrentInstance().addMessage("userNameField", "Sorry, 
> that username is unknown");
>     return "input";
>   }
> }
> 
> Notice MyAction inherits no JSF-specific interfaces and extends no 
> JSF-specific classes, which is I find very desirable.

Well... Obviously code-coupling is bad. You're still coupled to the
FacesContext, though, and in some ways I like being coupled to static methods
even less because it's not injectable.

> Just wondering if struts2 has a way to decouple actions in this manner. 

Not that I know of, although it has some appeal. The ActionContext docs
pretty much state what is available in the current iteration of S2/XWork.

An action's errors / messages / etc. are part of the action itself, and the
validation framework and the tags that retrieve those messages rely on
calling those action methods for adding / retrieving the collection of
messages etc.

Dave


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


Re: Actions without extending ActionSupport?

Posted by er...@bbh.com.
Hi David,

Thanks again for the reply. I'm comparing MVC frameworks right now, and 
wondering if struts2 has a similar feature to JSF. In JSF, an action can 
look like this:

public class MyAction {

  public String deleteUser() {
    // Here I can inject errors for display on the JSP by writing:
    FacesContext.getCurrentInstance().addMessage("userNameField", "Sorry, 
that username is unknown");
    return "input";
  }
}

Notice MyAction inherits no JSF-specific interfaces and extends no 
JSF-specific classes, which is I find very desirable.
Just wondering if struts2 has a way to decouple actions in this manner. 
Spring-MVC does not and, of course, struts1 does not.

Thank you.





--- tom_brokaw <er...@bbh.com> wrote:
> I said:
>> You don't *need* to extend ActionSupport to implement ValidationAware,
>> it's just much easier.
> 
> So I *must* implement an interface (ValidationAware) or extend a struts2
> class in order to add errors messages from an action. Is that accurate?

If you want the framework to recognize those errors, be able to use them 
in
tags, etc. or make decisions based on their presence (or not), use the
validation framework (which expects to be able to add messages based on 
the
ValidationAware interface) then yes.

If you want to create your own framework for handling errors then you can 
do
whatever you want.

Dave



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



*************************** IMPORTANT
NOTE***************************** The opinions expressed in this
message and/or any attachments are those of the author and not
necessarily those of Brown Brothers Harriman & Co., its
subsidiaries and affiliates ("BBH"). There is no guarantee that
this message is either private or confidential, and it may have
been altered by unauthorized sources without your or our knowledge.
Nothing in the message is capable or intended to create any legally
binding obligations on either party and it is not intended to
provide legal advice. BBH accepts no responsibility for loss or
damage from its use, including damage from virus.
************************************************************************

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


Re: Actions without extending ActionSupport?

Posted by Dave Newton <ne...@yahoo.com>.
--- tom_brokaw <er...@bbh.com> wrote:
> I said:
>> You don't *need* to extend ActionSupport to implement ValidationAware,
>> it's just much easier.
> 
> So I *must* implement an interface (ValidationAware) or extend a struts2
> class in order to add errors messages from an action. Is that accurate?

If you want the framework to recognize those errors, be able to use them in
tags, etc. or make decisions based on their presence (or not), use the
validation framework (which expects to be able to add messages based on the
ValidationAware interface) then yes.

If you want to create your own framework for handling errors then you can do
whatever you want.

Dave



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


Re: Actions without extending ActionSupport?

Posted by tom_brokaw <er...@bbh.com>.

>> I was under the impression that I could write actions without extending
>> ActionSupport or implementing any struts2/xwork interfaces. 

>You can. Doesn't mean you'd *want* to, if you want to use functionality
>provided by the framework.

I want to do this so that I can minimize the coupling between my actions and
struts2. JSF permits this. You still have to call a static method to add
validation errors messages from actions, but at least you don't have to
extend a class or implement an interface. I was hoping struts2 had a similar
approach.

>You don't *need* to extend ActionSupport to implement ValidationAware, it's
>just much easier.

So I *must* implement an interface (ValidationAware) or extend a struts2
class in order to add errors messages from an action. Is that accurate?

thanks very much,
tom

-- 
View this message in context: http://www.nabble.com/Actions-without-extending-ActionSupport--tp15591064p15593697.html
Sent from the Struts - User mailing list archive at Nabble.com.


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


Re: Actions without extending ActionSupport?

Posted by Dave Newton <ne...@yahoo.com>.
--- tom_brokaw <er...@bbh.com> wrote:
> I was under the impression that I could write actions without extending
> ActionSupport or implementing any struts2/xwork interfaces. 

You can. Doesn't mean you'd *want* to, if you want to use functionality
provided by the framework.

> However, I
> cannot figure out how to add action errors (ActionSupport.addActionError())
> to an action if not extending ActionSupport. I looked at
> ActionContext.getContext() and ServletActionContext, but don't see a way to
> add action errors.
> 
> Anyone know how to do this?

You don't *need* to extend ActionSupport to implement ValidationAware, it's
just much easier.

Dave


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