Matt,
I prefer the second solution.
I don't see having interceptors in a particular order as a big issue.
We should already be used to the concept from servlet filters, plus it seems
logical that the interceptors are applied the way they are put in the config
file.
Cheers,
Mathias
-Original
On Tuesday, July 1, 2003, at 11:07 PM, Jason Carreira wrote:
Did you put the Interceptor in your interceptor stack to set up the
components? It looks like this:
interceptor name=component
class=com.opensymphony.xwork.interceptor.component.ComponentIntercepto
r
/
doh! sorry for the boneheaded
On Tuesday, July 1, 2003, at 11:14 PM, Jason Carreira wrote:
Ok, so this is how you turn off validation when coming into a
page, but
turn it on when coming out?
Exactly. You can apply validators at the alias level or at the Action
class level (based on the validator file name). The alias level
I assuming since this is during your servlet's init method, you want
access to components with an application lifespan. The following code
grabs the component manager for application lifecycle objects and tells
it to populate the instance of MyObject with all the appropriate components.
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Could you share an example of using an alias in this manner to
kick-start me some here?
I'm not sure how detailed you want, but...
Lets say you have an Action named EditFooAction.java.
You could have an
Did we lose ActionContext.getApplication() in favour of the
ServletActionContext one?
I thought the intent of that was a generic 'application scope' map that you
could get / set things into. For a servlet app, that maps (no pun intended)
back to the servlet context.
Mike
On 2/7/03 6:52 AM,
Matt,
Xdoclet generation is an evil of struts - because you need to write so much
crap just to fulfil it's contracts.
See http://blogs.atlassian.com/rebelutionary/archives/000176.html
For unit testing, screw Cactus! (sorry Vincent - it is really cool, but too
slow for any unit testing) Cactus
Erik,
That's exactly how it should work - the beauty of IoC! :)
Do you have the IoC filters / listeners installed? You need these to be
plugged in for the IoC system to work.
http://wiki.opensymphony.com/space/WebWork+2+Components
But what you're doing is how it should be done!
M
On 2/7/03
Jason Carreira wrote:
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
snip
A few other questions about WebWork:
- Is the Action interface going away? Mike axed it over the
weekend, locally, but what's the verdict?
Yep, I think that's pretty likely, but it's
Matt - thanks. That, of course, did the trick. I had stumbled on this
stuff and was close to discovering it myself. What I wanted to try to
avoid was constructing the AppConfig object itself. I presume this
would be done by getting the one the component manager created by
making my servlet
-Original Message-
From: Anthony Eden [mailto:[EMAIL PROTECTED]
If the Action interface is removed then will execute() be the default
command method? What is the reason for removing the Action
interface?
I believe I understand that it is no longer needed, but does
it
i've added pico support to xwork and webwork. i've also updated the
sample application in webwork to use pico. to use pico ioc, you'll need
to put the following to your web.xml file:
listener
listener-classcom.opensymphony.webwork.lifecycle.PicoApplicationLifecycleListener/listener-class
How are the Actions instantiated? Before, it was doing newInstance()
from the class in the DefaultActionInvocation... I assume you replace
the ActionProxyFactory in the lifecycle listener?
-Original Message-
From: Matt Ho [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 10:34
public void testSuccessfulLogin() throws Exception {
parameters.put(username, new String[]{savaki});
parameters.put(password, new String[]{password});
ActionProxy proxy = ActionProxyFactory.getFactory().
createActionProxy(/member, login, extraContext, false);
String result =
Why is WebWorkPicoContainer in XWork?
-Pat
- Original Message -
From: Jason Carreira [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 7:51 AM
Subject: RE: [OS-webwork] pico support available
How are the Actions instantiated? Before, it was doing newInstance()
Jason Carreira wrote:
-Original Message-
From: Anthony Eden [mailto:[EMAIL PROTECTED]
snip
On a side note, does anyone else notice that the use of
dynamic proxies
is leading to code which acts more like dynamic typed
languages such as
Python?
Sincerely,
Anthony Eden
No...
While I'm not sure that the ActionProxy stuff is heading in that direction,
believe me when I say I also don't think that getting rid of interfaces is a
great thing. Pico is doing that (it calls start() and stop() using
reflection rather than Startable and Stopable). Likewise, at one point XWork
Even me, Mr. eXtreme XDoclet, has reservations about generating the
-validation.xml files if you are serving up your model directly from
your actions. Although, since the validation is completely decoupled
from the web (and this is no difference in Struts), perhaps it does
make sense.
The
It is an implementation of the Proxy Pattern, but it's not dynamic
proxies. It uses reflection.
-Original Message-
From: Anthony Eden [mailto:[EMAIL PROTECTED]
No... Because they're strongly typed. But we're not using dynamic
proxies here...
How do you mean you're not using
Actually, it does make sense to have the idea of different contexts for
validating domain objects. At Notiva, some people took the validation
stuff from Xwork and built a pattern for validating our business objects
using the Visitor Pattern to bring the validation down to the sub-object
level. We
Yeah I know, I debated it with Mike yesterday, and I do see that that
it's easy to remove etc, but I just don't like using reflection for yet
another thing. Sure it's much faster that it used to be, but it's still
slower than a direct method call, so the gain to me is twofold, getting
rid
This cannot be the Pat I've grown to distrust and have no faith in, but
I must say I really really like this new guy who has hijacked his email
account and is posting about why getting rid of Action is Not a Good
Thing
On Wednesday, July 2, 2003, at 02:32 PM, Pat Lightbody wrote:
I don't
If you pass false as the last argument to createActionProxy, it won't
call the Result so you can save yourself to MockResult :)
M
Ara Abrahamian wrote:
public void testSuccessfulLogin() throws Exception {
parameters.put(username, new String[]{savaki});
parameters.put(password, new
Well, as you know, my style of development has been to avoid command
altogether. They feel flakey to me, so I always use the execute() method.
At the end of the day, the object is an action, therefore it should actually
BE an Action.
-Pat
- Original Message -
From: Jason Carreira [EMAIL
Pat Lightbody wrote:
While I'm not sure that the ActionProxy stuff is heading in that direction,
believe me when I say I also don't think that getting rid of interfaces is a
great thing. Pico is doing that (it calls start() and stop() using
reflection rather than Startable and Stopable).
I made this argument before and I think it still stands. I may not like
Struts, but I can pick up any piece of struts code and look for the
execute (or perform for older stuts code) method and know that's a
starting point.
Without the Action interface, I'm forced to wander through the code
I was present during the let's remove the Action interface
discussions at 1am last Friday night (errr... Saturday morning). I
didn't have any opinion at the time since I hadn't been in the code,
not to mention I was barely able to stay awake.
I agree with what Pat is saying. Interfaces
While we're bringing up controversial topics
A while back Mike refactored ActionSupport to have a parent class,
BaseActionSupport, that does most of the work, and put the old workflow
stuff into ActionSupport:
public String execute() throws Exception {
doValidation();
if
I've obviously missed something important here, but why exactly do people
need methods other than execute()? An Action should be composed of *one*
action, not multiple actions designated by method names.
Blake
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
+1. This type of behavior should be pluggable.
M
Jason Carreira wrote:
While we're bringing up controversial topics
A while back Mike refactored ActionSupport to have a parent class,
BaseActionSupport, that does most of the work, and put the old workflow
stuff into ActionSupport:
public
I have tried migrating my quite large app to WW2, these are my issues with
it:
http://wiki.opensymphony.com/space/WebWork+2+Migration+Guide specifies that:
ActionSupport has moved from webwork.ActionSupport to
com.opensymphony.xwork.ActionSupport,
but a deprecated webwork.ActionSupport and
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 3:53 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Default workflow
Sounds great! I was going to suggest something similar with the
ValidationInterceptor. It was confusing
Yeah, we're definitely lacking on the docs. My schedule will be freeing
up in two weeks so I'll be able to put more effort into that.
M
boxed wrote:
I have tried migrating my quite large app to WW2, these are my issues with
it:
http://wiki.opensymphony.com/space/WebWork+2+Migration+Guide
On Wednesday, July 2, 2003, at 03:35 PM, Jason Carreira wrote:
I find it very useful to have multiple entry points to one Action, so
you don't have to have a proliferation of Action classes and they can
share common properties and validations... If you don't have this, you
end up with people
This is how WW1.x command driven actions are implemented. What I don't
like about this implementation is that anyone who know a little bit
about how WW works can twiddle with URLs to call other methods. Maybe
not a huge risk, but just ugly.
People can choose not to use different methods on their
See below...
-Original Message-
From: boxed [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 3:59 PM
To: [EMAIL PROTECTED]
Subject: [OS-webwork] WW2 migration
I have tried migrating my quite large app to WW2, these are
my issues with
it:
On Wednesday, July 2, 2003, at 04:29 PM, Jason Carreira wrote:
This is how WW1.x command driven actions are implemented. What I don't
like about this implementation is that anyone who know a little bit
about how WW works can twiddle with URLs to call other methods. Maybe
not a huge risk, but just
Yes, I agree. In my environment I'd set up conventions that all
actions that have validations must have an input mapping, and would
rather use an interceptor that took care of things automatically and
avoid having to subclass ActionSupport. But I agree it should not be
mandated and
If you set up your interceptors to have the StaticParameterInterceptor
AFTER the ParameterInterceptor (which I would suggest is a good
practice) then static configuration will override runtime parameters.
I'm really talking about when you don't pass a method param (which, with
CommandDriven and
Jason Carreira wrote:
snip
I would like to undo this, pull the implementation stuff up into
ActionSupport, get rid of the workflow and BaseActionSupport, and create
a DefaultWorkflowInterceptor which will call validate() on the Action if
it implements an Interface, then check for errors like above
Haha! This must be from that new mail client - BileMail! :)
On 3/7/03 4:39 AM, Hani Suleiman ([EMAIL PROTECTED]) penned the words:
This cannot be the Pat I've grown to distrust and have no faith in, but
I must say I really really like this new guy who has hijacked his email
account and is
Well, the drawback is that now you need a hack interceptor to intercept
attempts to misuse the dispatch action... Plus, the DispatchAction feels
very... Struts :-)
Seriously, being able to specify the method to call in the action
element is much more clear to me than setting a method param...
OK - I'll say again - it IS optional AND explicit :)
(One way to make it more explicit is make execute() final in AS?)
If you don't want 3 phase action support (for want of a better name) - use
BaseActionSupport - which provides error messages and i18n.
If you DO want it, use ActionSupport -
Bruce,
Does the BaseAS / AS separation not do this for you?
Mike
On 3/7/03 7:05 AM, Bruce Ritchie ([EMAIL PROTECTED]) penned the
words:
Jason Carreira wrote:
snip
I would like to undo this, pull the implementation stuff up into
ActionSupport, get rid of the workflow and BaseActionSupport,
[migration classes]
These were added by Patrick a while back, and it was decided to remove
them, rather than carry over old stuff. It's suggested that you extend
from com.opensymphony.xwork.ActionSupport instead, possibly having a
parent class for your actions which provides the calls to
This causes another ModelDriven problem. If the
StaticParameterInterceptor comes after the ParametersInterceptor, then
how can the proposed ModelDrivenInterceptor utilize static config
information?
M
Jason Carreira wrote:
If you set up your interceptors to have the StaticParameterInterceptor
Anders,
Well - those are interesting points.
A) a list of docs that we need to help migration would be _fantastic_.
Perhaps create a skeleton on the Wiki with the points you had trouble with?
I'd be more than happy to fill out the content.
B) The *Aware interfaces are interesting - they have
If you DO want it, use ActionSupport - which subclasses the above and
provides a doValidation, doDefault, doExecute cycle.
It _also_ provides backward compatibility (damn I sound like Hani
here!) which is a good thing as there is no real need to break it
unnecessarily?
I maintain that 95%
Amen brother!
-Original Message-
From: Mike Cannon-Brookes [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 5:17 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWork2, here I come!
IMHO this is just over complicating things.
Regardless of the _removal_ of
The ModelDrivenInterceptor could access the ActionContext to get params
and become totally independent of ordering. Just thought of that..
-Original Message-
From: Matt Ho [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 5:25 PM
To: [EMAIL PROTECTED]
Subject: Re:
Or, you could apply the StaticParamInterceptor before ModelDriven and
again after ParamInterceptor...
-Original Message-
From: Jason Carreira
Sent: Wednesday, July 02, 2003 5:56 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] WebWork2, here I come!
The ModelDrivenInterceptor
I think what would be really useful for the discussion are some concrete
examples of pojos that would make use of multiple entry points.
Certainly the workflow we've been talking about is one example, but I'd
like to understand what some others are.
M
Jason Carreira wrote:
Amen brother!
That just seems wrong :)
Jason Carreira wrote:
Or, you could apply the StaticParamInterceptor before ModelDriven and
again after ParamInterceptor...
-Original Message-
From: Jason Carreira
Sent: Wednesday, July 02, 2003 5:56 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] WebWork2,
OK - but I don't see (at a glance) how this is done in an interceptor?
It surely needs a base class, to call the 3 methods in the right order?
M
On 3/7/03 7:26 AM, Jason Carreira ([EMAIL PROTECTED]) penned the
words:
I think you misunderstood... I don't want to remove it, per se, I want
to
Here are my observations on the Action issue:
From a framework standpoint it doesn't really matter if there is an explicit
execute() method to call on the underlying object. The default behavior is
to call this method if no method is specified. So I don't think we lose
anything by changing the
Matt,
Well, there are tonnes of use cases for this (you are talking about commands
right?)
The most commonly quoted one is a CRUD action. You create different methods
like doCreate(), doUpdate() and have the same fields (ie name, email etc).
?
M
On 3/7/03 8:11 AM, Matt Ho ([EMAIL PROTECTED])
Uhm - just FYI the result types are currently in Action interface, so
anything that implements it gets those :)
M
On 3/7/03 8:47 AM, Brock Bulger ([EMAIL PROTECTED]) penned the words:
Here are my observations on the Action issue:
From a framework standpoint it doesn't really matter if there
Why remove the execute() method? That's the heart of the Command pattern.
If you're going to keep the interface (which I would prefer), you should
keep the one important element: the execute() method.
Blake
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf
Yep. That's why we are having this problem. Jason and others want the return
types without having to implement a specific method. If they were separate,
we probably wouldn't be having this issue!
- Brock
- Original Message -
From: Mike Cannon-Brookes [EMAIL PROTECTED]
To: [EMAIL
Well, there are tonnes of use cases for this (you are talking about
commands right?)
The most commonly quoted one is a CRUD action. You create different
methods like doCreate(), doUpdate() and have the same fields (ie name,
email etc).
Ha! I've definitely spent too much time with Struts :)
Matt Ho wrote:
Well, there are tonnes of use cases for this (you are talking about
commands right?)
The most commonly quoted one is a CRUD action. You create different
methods like doCreate(), doUpdate() and have the same fields (ie name,
email etc).
Ha! I've definitely spent too
On Wednesday, July 2, 2003, at 06:56 PM, Mike Cannon-Brookes wrote:
Well, there are tonnes of use cases for this (you are talking about
commands
right?)
The most commonly quoted one is a CRUD action. You create different
methods
like doCreate(), doUpdate() and have the same fields (ie name,
On Wednesday, July 2, 2003, at 05:12 PM, Jason Carreira wrote:
Well, the drawback is that now you need a hack interceptor to intercept
attempts to misuse the dispatch action... Plus, the DispatchAction
feels
very... Struts :-)
Uh damn did you look at @author tags in the Struts codebase
Yeah, it probably is... But if you're only setting params in the static
params that you're not going to care about after the
ModelDrivenInterceptor runs, then you don't have to worry about whether
the request parameters override those parameters, so you can have it do:
StaticParameters -
Like I said before, I don't want to have to have subclasses to handle
this stuff. This is a common enough pattern that it should be handled
for me by the framework.. What's more, if you guys would lose the
Interface hangup, we could call any classes, even 3rd party :-)
I do agree about the doXXX
Here's the class. I'm assuming here that we'd create another Interceptor
if we want it to call a validate() method on the Action... If you don't
use this, you could just use the regular ValidationInterceptor.
public class DefaultWorkflowInterceptor implements Interceptor {
/**
* Called
Apologies for my Australian-ism - but your subclass structure is bullshit :)
Why do that? It's far too complex. Just have doCreate(), doRead() etc and
use the code as is. This is exactly what it was designed for?
And as for your analysis of AS - exactly correct, except for the interceptor
bit.
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 9:17 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWork2, here I come!
On Wednesday, July 2, 2003, at 05:12 PM, Jason Carreira wrote:
Well, the drawback is that now you
From what I've seen of WW2 so far and comparing how I'd apply it
against our current Struts app, I'd still use Action/execute, perhaps
with my own base class to provide a thin layer of control. I'd use a
validating interceptor that kicked back INPUT without calling execute,
and I'd be able
You can call them whatever you want - that's the whole idea!
(Personally doX() is good as it separates executing methods from other
methods - but use whatever floats your boat)
M
On 3/7/03 11:44 AM, Jason Carreira ([EMAIL PROTECTED]) penned the
words:
Like I said before, I don't want to have
Mike Cannon-Brookes wrote:
Apologies for my Australian-ism - but your subclass structure is bullshit :)
Hahaha. Ok, I'll just keep it to myself then :)
Why do that? It's far too complex. Just have doCreate(), doRead() etc and
use the code as is. This is exactly what it was designed for?
This
I might have missed something. See below.
- Original Message -
From: Jason Carreira [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 8:26 PM
Subject: RE: [OS-webwork] WebWork2, here I come!
See below...
-Original Message-
From: Brock Bulger
Umm... We're not talking about changing the return type...
We're talking about removing the Action Interface.
b: If you remove the Action interface you have to do
something with the
getAction() method on the ActionProxy, right? My test cases
usually have to cast this object to
73 matches
Mail list logo
