Re: [OS-webwork] WebWork2, here I come!
On Wednesday, July 2, 2003, at 10:30 PM, Jason Carreira wrote: Sheesh! :) So make the framework set parameters from the action element too! Look at Ant's DynamicConfigurator interface for inspiration ;) See, but there's the problem I had with WW1.x... You had configuration constructs for Commands, but the whole CommandDriven stuff was implemented in ActionSupport. This needs to be core in configuration, and it needs to be core in the framework. Ya lose me with comparisons to WW1.x since I have never used it, sorry. I'm still waiting to hear convincing arguments as to why I should change working code or why I'd want to use class hierarchies Having to subclass things is EXACTLY what I want to avoid... It was a huge hassle in WW1.x. But aren't you subclassing something already? ActionSupport? Or your actions are truly POJO's with no base class? I hear what you are saying loud and clear. I don't want to keep bringing up Struts, as I want to put it out of my mind, but Action in Struts is a base class. Evil! It should have been an interface from the start. Subclassing Action then gets you into trouble because eventually you'll want to leverage ForwardAction, or DispatchAction, or the wonderful LookupDispatchAction :). But since you've done the BaseAction construct you're screwed except for delegation somehow, or doing multiple BaseXXXAction subclasses which is hideous. You would not need to subclass in WW2 to get dispatching like you want. Implement Action, have a setMethod, and key off method in execute(). I see your point that you'd have to do that in all your actions that dispatch, and thus we're now back to subclassing to centralize. Can we see what your actions look like and how they work so I can see your use-case (err... user story!)? Most of my web apps simply have a single action and dispatching is not something I've had much need for, but maybe its because my apps are just more simplistic than yours? Well, this is not exactly the same. I don't want to be loose with data types or anything like that. Reflective method calls are a pretty well understood and low-risk technology. My main argument against making it truly dynamic like it is now is the cross-referencing needed to find out the flow and how an action is working. Someone (Patrick?) mentioned this earlier. I also like the idea of the _pure_ command pattern. Like I've said though, I'm still learning and your discussion is persuasive. Inheritance is the last OO thing we want to burn up, so I'm in complete agreement with you on avoiding it - this is why I'm cringing with ActionSupport and such rather than letting smarter interceptors take care of some of that (like rejecting execute() when validation fails - would making this a parameter on the builtin interceptor be reasonable? Or a separate one to do that?). Erik --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] WebWork2, here I come!
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
See, but there's the problem I had with WW1.x... You had
configuration
constructs for Commands, but the whole CommandDriven stuff was
implemented in ActionSupport. This needs to be core in
configuration,
and it needs to be core in the framework.
Ya lose me with comparisons to WW1.x since I have never used
it, sorry.
The idea is that we had stuff for configuring multiple entry points in
the config file (core) but the actual implementation was a detail of the
way ActionSupport was implemented.
But aren't you subclassing something already?
ActionSupport? Or your
actions are truly POJO's with no base class?
I probably WOULD subclass ActionSupport, but if I have a reason NOT to,
I don't want to lose core functionality.
I hear what you are saying loud and clear. I don't want to keep
bringing up Struts, as I want to put it out of my mind, but Action in
Struts is a base class. Evil! It should have been an interface from
the start. Subclassing Action then gets you into trouble because
eventually you'll want to leverage ForwardAction, or
DispatchAction, or
the wonderful LookupDispatchAction :). But since you've done the
BaseAction construct you're screwed except for delegation somehow, or
doing multiple BaseXXXAction subclasses which is hideous.
You would not need to subclass in WW2 to get dispatching like
you want.
Implement Action, have a setMethod, and key off method in
execute().
I see your point that you'd have to do that in all your actions that
dispatch, and thus we're now back to subclassing to centralize.
Can we see what your actions look like and how they work so I can see
your use-case (err... user story!)? Most of my web apps
simply have a
single action and dispatching is not something I've had much
need for,
but maybe its because my apps are just more simplistic than yours?
It's very useful for CRUD actions:
public String edit() {
try {
model = persistenceManager.load(MyClass.class, id);
} catch (Exception e) {
addActionError(e.toString());
return ERROR;
}
return SUCCESS;
}
public String save() {
try {
persistenceManager.save(model);
} catch (Exception e) {
addActionError(e.toString());
return ERROR;
}
return SUCCESS;
}
Public String delete() {
try {
persistenceManager.delete(MyClass.class, id);
} catch (Exception e) {
addActionError(e.toString());
return ERROR;
}
return SUCCESS;
}
Well, this is not exactly the same. I don't want to be
loose with data
types or anything like that. Reflective method calls are a
pretty well
understood and low-risk technology.
My main argument against making it truly dynamic like it is
now is the
cross-referencing needed to find out the flow and how an action is
working. Someone (Patrick?) mentioned this earlier. I also like the
idea of the _pure_ command pattern. Like I've said though, I'm still
learning and your discussion is persuasive. Inheritance is
the last OO
thing we want to burn up, so I'm in complete agreement with you on
avoiding it - this is why I'm cringing with ActionSupport and
such
rather than letting smarter interceptors take care of some of that
(like rejecting execute() when validation fails - would making this a
parameter on the builtin interceptor be reasonable? Or a
separate one
to do that?).
Erik
Either one of those would work. The reason I was talking about a
separate interceptor for short-circuiting the processing was because you
might have different validator interceptors... We've got the one now
that looks up validations via XML files, but we could also have one to
call a validate() method on the action... Then we'd need the same check
for errors and return INPUT for both of these... Instead it could be one
DefaultWorkflowInterceptor that you apply after these.
Jason
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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 validators are added to the action level validators (and superclass validators, etc) to build up the whole list. In this way you can have some validators for one alias, but not the other. Could you share an example of using an alias in this manner to kick-start me some here? Definitely resource loading should be pluggable. Having resources statically in a WAR always seemed odd to me with Struts. I don't know how good the Commons Resource code is (yes, I recognize the questionable quality of Jakarta stuff too guys, and take what is good and bitch about what is bad!) but if its a decent enough abstraction, then lets use it. If it sucks, then not. Thoughts on this? I'm open to this... What are its dependencies? The project.xml lists several, so it looks too heavy duty for what xwork/webwork would want: http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/resources/ project.xml?annotate=1.3 A few other questions about WebWork: - Is the Action interface going away? Mike axed it over the weekend, locally, but what's the verdict? - How do you use other methods other than execute() in an Action? - I still haven't fully grasped xwork.xml yet. What do packages do and how/why would I use them (let's keep this web-app specific so its more concrete for the sake of discussion)? - Namespaces - this looks like what I need to do in order to isolate sections of our app (/profile, /events, etc) and keep them consolidated in one spot. Nice. I'll give this a try. - Interceptor stacks - I see the debugStack in there. How would I go about using it? I'm assuming I just add an interceptor-ref element to the actions I wanted, or to the defaultStack to apply to all actions, right? The wiki has been immensely helpful. Once I get all the pieces to my proof-of-concept app. completed I'll add some of what I learn back to it (the validation page, particularly, needs a bit more info to really make it work). Erik --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] WebWork2, here I come!
-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 EditFooAction-validation.xml with one Field validator, a Required validator on an Integer property named id. This action could be mapped in the xwork.xml with 2 aliases, editFoo and saveFoo with corresponding methods editFoo and saveFoo on the Action. In this case, you wouldn't have any extra validations applied for the editFoo alias, while for the saveFoo alias, you would validate all of the fields of a Foo object. This way, you can re-use the common pieces, having an id property and a Foo object (either returned from getModel() or getFoo(), if you want to access your properties as foo.bar) and they can share the same Foo edit form. 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 good to discuss it here. - How do you use other methods other than execute() in an Action? You set the method=commandMethod attribute in the action element in xwork.xml. Check out the xwork.xml in the root of the test source under Xwork. It tests all of the functions and pieces of xwork.xml. - I still haven't fully grasped xwork.xml yet. What do packages do and how/why would I use them (let's keep this web-app specific so its more concrete for the sake of discussion)? It allows you to do a couple of things: 1) Apply a namespace to a set of actions 2) Apply package globals to a set of actions, such as global-results 3) Define interceptors for a group of actions 4) Inherit these settings from another package 5) Create a reusable sub-app by bundling a config file, a set of Action classes, and a set of velocity templates into a Jar file and use the include file=include.xml/ to load it from the classpath - Namespaces - this looks like what I need to do in order to isolate sections of our app (/profile, /events, etc) and keep them consolidated in one spot. Nice. I'll give this a try. Yep. This allows the actions to be easily secured, as well. - Interceptor stacks - I see the debugStack in there. How would I go about using it? I'm assuming I just add an interceptor-ref element to the actions I wanted, or to the defaultStack to apply to all actions, right? The defaultStack is not applied unless you want it to be. Check out the xwork.xml in the test source tree under Xwork. You apply interceptors and interceptor stacks the same way, via an interceptor-ref with the name. You can also apply a defult interceptor ref for a package using this notation in your xwork.xml under a package: default-interceptor-ref name=timer / Which will be applied to all actions in a package which don't have any interceptor refs. The wiki has been immensely helpful. Once I get all the pieces to my proof-of-concept app. completed I'll add some of what I learn back to it (the validation page, particularly, needs a bit more info to really make it work). Erik Ok, sounds great! --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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, Jason Carreira ([EMAIL PROTECTED]) penned the words: Well, I'm glad to hear it But now you're making me work... See below... -Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 12:39 PM To: [EMAIL PROTECTED] Subject: [OS-webwork] WebWork2, here I come! I just wanted to drop a note that I'm almost a switcher to WW2. I've gotten my demo app that I use for all of my Ant, XDoclet, Lucene, and Struts presentations working just fine in WW2. Thanks to all that contributed to the wiki and sample app. where I learned enough to make it work. I'm on the process of plugging in validation, so I cannot comment on that yet. My app is a simple single-form and action with a simple String setter (think of a Google page, q=...). I do have a few initial questions to get myself rolling even further along to being a complete switcher: - How do I get to my application context attributes? I set some in an initialization servlet from its init-param's. Check out ServletActionContext.getServletContext(). This should let you do what you want to do (at the expense of not being able to use your Action outside a Servlet container, but you're used to Struts, so we forgive you :-)) - I plan on refactoring my infamous custom:label taglib in Struts to the comparable piece in WW2. Can someone point me in the right direction to grab the validation metadata so I can tell if a field is required or not, as well as getting at the errors from the validation so I can turn the label red? Or is there already infrastructure in place to make this unneeded or easier? It's very easy to check for errors. If your Action implements ValidationAware (or extends ActionSupport or BaseActionSupport) then this is built in, as errors will be added to your action and you can use hasErrors(), hasActionErrors(), hasFieldErrors(), getActionErrors(), and getFieldErrors() depending on what you need. For the validation metadata You can use ActionValidatorManager.getValidators(ActionInvocation invocation) to get them... You can get the ActionInvocation from the ActionContext. Unfortunately, this will return you a list of validators. You can check if they're FieldValidators and get the field name to compare... I realize this is not ideal for what I think you're trying to do. I'm open to changing / adding to make this easier, if you've got some ideas. The other challenge that you might face is if you want these tags to work when the page is rendered without coming through an Action... We've had some challenges there as far as not having an ActionInvocation yet. You'll probably also want to know not the validators on THIS alias, but the alias you're going to send the request TO. Yeah. Challenges. :-) Maybe we could work to make them work inside the Form tag, and have that have the ability to set the namespace and action alias for the sub-tags to access, then add another access method for looking up the validators using the namespace and alias to ActionValidatorManager. Great work, everyone! WW2 passed the 15-minute rule of being able to pull it down and immediately be effective with it. There is still a way to go for me to fully implement all the pieces our current app can do (the main additional piece has to do with custom resource handling, not from a properties file but a DB instead). This sounds cool... We could make resource loading pluggable, like we have for configuration, so message bundles can be pulled from other sources than just properties files. Perhaps at the next TheServerSide Symposium I'll do an Advanced WebWork presentation instead! :) (oops... Jason said he wanted that one, so its all his!). Heh :-) I think there's going to be lots to talk about Erik p.s. I'm current on the list in digest mode, but will likely switch to individual messages as my WW2 usage cranks up. We're just glad to have you... Next we'll convert Matt Raible, then we'll teach Craig McClanahan the error of his ways... LOL Jason --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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 is meant for acceptance testing.
public void testMyAction()
{
MyAction action = new MyAction();
action.setId(10);
String result = action.execute();
assertEquals(Action.SUCCESS, result);
}
That will run VERY fast :) Occasionally you need to execute an action
through WW's framework (ie to test validations or IoC) but even that's not
too difficult - just a line or two more using ActionProxy's.
As for indexed properties, I don't know what they are?
Mike
On 2/7/03 7:09 AM, Raible, Matt ([EMAIL PROTECTED]) penned the
words:
If you can give me XDoclet generation of the validations (server-side +
client side) like Struts has, and provide Cactus integration like
StrutsTestCase, I might be interested. Of course, then I'll have to learn
SiteMesh over Tiles (or use Tiles with WW) and hope that WW supports indexed
properties (I'm sure it does).
Erik has defected... damn... ;-)
Raible
-Original Message-
From: Hani Suleiman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 01, 2003 2:57 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWork2, here I come!
On Tuesday, July 1, 2003, at 04:52 PM, Jason Carreira wrote:
We're just glad to have you... Next we'll convert Matt Raible, then
we'll teach Craig McClanahan the error of his ways... LOL
All that'd be left to do after that is get him to drop the devil-spawn
abomination sometimes knows as JSF, and there might hope yet for the
web portion of j2ee.
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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 good to discuss it here. 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 provide any benefit to Java developers who are comfortable with implementing an interface in order to establish a contract. 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 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] WebWork2, here I come!
-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 provide any benefit to Java developers who are comfortable with implementing an interface in order to establish a contract. Execute() will remain the default, just like it is now. Java developers who want some comfort can extend ActionSupport, which handles most everything for you. 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... Because they're strongly typed. But we're not using dynamic proxies here... Jason --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] WebWork2, here I come!
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 = proxy.execute();
assertEquals(Action.SUCCESS, result);
LoginAction action = (LoginAction)proxy.geAction();
// do more assertions here
}
Programmable ActionProxy is really awesome! Combined with a custom
ConfigurationProvider object you can test the action very easily, you
can just enable the ValidationInterceptor for example and easily unit
test all your externalized validation.xml settings too!
We created an abstract base class for all xwork tests. It configures an
ActionProxy object. ValidationInterceptor is added to the list of
interceptors and a MockResult is installed as the only result type.
public abstract class AbstractXWorkTest extends TestCase
{
private ActionProxy proxy;
private Class actionClass;
public AbstractXWorkTest( Class actionClass )
{
this.actionClass = actionClass;
}
protected void setUp() throws Exception
{
setUp(actionClass, actionClass.getName(), null);
}
/**
* Use this method if you want to setup this test with a specific
action class and method.
*
* This will throw out all previous configuration done by the normal
setUp() method.
*/
protected void setUp(Class clazz, String alias, String method)
throws Exception
{
ConfigurationManager.addConfigurationProvider(
createConfigurationProvider( method, alias ) );
ConfigurationManager.getConfiguration().reload();
proxy = ActionProxy.createActionProxy( , alias, new HashMap()
);
}
protected TestConfigurationProvider createConfigurationProvider(
String method, String alias )
{
return new TestConfigurationProvider(method, alias);
}
protected void tearDown() throws Exception
{
ConfigurationManager.clearConfigurationProviders();
super.tearDown();
}
protected Action getAction()
{
return proxy.getAction();
}
protected ActionProxy getActionProxy()
{
return proxy;
}
protected class TestConfigurationProvider implements
ConfigurationProvider
{
private String methodName;
private String alias;
public TestConfigurationProvider(String methodName, String
alias)
{
this.methodName = methodName;
this.alias = alias;
}
public void init( Configuration config )
{
PackageConfig defaultPackageConfig = new PackageConfig();
HashMap results = createResultTypes();
List interceptors = createInterceptors();
ActionConfig fooActionConfig = new ActionConfig( methodName,
actionClass, new HashMap(), results, interceptors );
defaultPackageConfig.addActionConfig( alias, fooActionConfig
);
config.addPackageConfig( defaultPackage,
defaultPackageConfig );
}
protected HashMap createResultTypes()
{
HashMap results = new HashMap();
ResultConfig resultConfig = new ResultConfig(
def-result-type, MockResult.class, new HashMap() );
results.put( Action.SUCCESS, resultConfig );
return results;
}
protected List createInterceptors()
{
List interceptors = new ArrayList();
interceptors.add( new ValidationInterceptor() );
return interceptors;
}
public void destroy()
{
}
public boolean needsReload()
{
return false;
}
}
}
Just do this to test a TestCreatePageAction derived test case do
something like this:
assertEquals( Action.SUCCESS, getActionProxy().execute() );
assertEquals( 1, getCreatePageAction().getActionErrors().size() );
assertEquals( getCreatePageAction().getText( space.key.empty ),
getCreatePageAction().getActionErrors().iterator().next() );
assertEquals( 0, getCreatePageAction().getFieldErrors().size() );
That's it. Hope it was useful for those who were thinking about unit
testing their xwork action classes :-)
Ara.
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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... Because they're strongly typed. But we're not using dynamic proxies here... How do you mean you're not using dynamic proxies? What the heck is ActionProxy then? The actual command method which is invoked can vary depending on the configuration. Granted this is not dynamic typing as seen in Python and other scripting languages, but it still feels like we are moving in that direction, i.e. Java is attempting to become more of a dynamic language (where less and less is defined at compile-time). FWIW, my comment is also based on the increased interest in interaction between Java and scripting languages so perhaps I should have included a little bit more context for my comment. Sincerely, Anthony Eden --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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 wasn't going to have an Action interface for the execute() method, but I and others bitched enough to keep it. So don't worry Hani and Anthony, we won't abandon you :P -Pat - Original Message - From: Hani Suleiman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 9:00 AM Subject: Re: [OS-webwork] WebWork2, here I come! I agree completely. All this 'just define it/figure it out at runtime' stuff really bothers me. Interfaces might be very 'old school' now, but they are useful, just so you know at compile time what contracts your components/classes/whatever are adhering to. I still have yet to look at xwork (waiting for migration guides+tools and performance reports), but the concept of having all information in an xml file and an active effort to remove type safety/contracts from code feels very wrong. I understand the allure of 'but you can use ANYTHING as an action!', but I do feel that those things that are used as an action should anticipate somewhat that they are one and will be treated as one, in most cases. On Wednesday, July 2, 2003, at 11:54 AM, Anthony Eden wrote: 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... Because they're strongly typed. But we're not using dynamic proxies here... How do you mean you're not using dynamic proxies? What the heck is ActionProxy then? The actual command method which is invoked can vary depending on the configuration. Granted this is not dynamic typing as seen in Python and other scripting languages, but it still feels like we are moving in that direction, i.e. Java is attempting to become more of a dynamic language (where less and less is defined at compile-time). FWIW, my comment is also based on the increased interest in interaction between Java and scripting languages so perhaps I should have included a little bit more context for my comment. Sincerely, Anthony Eden --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/ 01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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 main issue I heard Jason mention with it was binding the knowledge of action aliases to specific validations. I agree that it doesn't really make sense to have action aliases in domain objects. XDoclet could do as little or as much of this type of thing that makes sense. At this point I'm still in learning mode and can comment further after building a few pieces by hand. Erik On Wednesday, July 2, 2003, at 12:43 PM, Ara Abrahamian wrote: Ah yeah I think the -validation.xml stuff is a good candidate for auto-geenration. I think xwork.xml is ok without xdoclet, but all those validation.xml files are just too much too take care of by hand. I'm ready to help anyone who's interested in implementing an xdoclet module for it. Ara. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] WebWork2, here I come!
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 dynamic proxies? What the heck is ActionProxy then? The actual command method which is invoked can vary depending on the configuration. Granted this is not dynamic typing as seen in Python and other scripting languages, but it still feels like we are moving in that direction, i.e. Java is attempting to become more of a dynamic language (where less and less is defined at compile-time). FWIW, my comment is also based on the increased interest in interaction between Java and scripting languages so perhaps I should have included a little bit more context for my comment. Sincerely, Anthony Eden --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_06 1203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] WebWork2, here I come!
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 have different validations depending on where we're getting the objects (batch loading from XML from a partner vs. data-entry, etc.) so we used the idea of context (the same as alias) for this. I'm planning on merging this code back into Xwork at some point. I'm still thinking about if we can make it simpler using reflection rather than the visitor object we use now that knows the structure of the business objects, but the basic idea is sound. Jason -Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 2:00 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WebWork2, here I come! 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 main issue I heard Jason mention with it was binding the knowledge of action aliases to specific validations. I agree that it doesn't really make sense to have action aliases in domain objects. XDoclet could do as little or as much of this type of thing that makes sense. At this point I'm still in learning mode and can comment further after building a few pieces by hand. Erik On Wednesday, July 2, 2003, at 12:43 PM, Ara Abrahamian wrote: Ah yeah I think the -validation.xml stuff is a good candidate for auto-geenration. I think xwork.xml is ok without xdoclet, but all those validation.xml files are just too much too take care of by hand. I'm ready to help anyone who's interested in implementing an xdoclet module for it. Ara. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_06 1203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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 of an unnecessarily slow invocation (reflection) as well as adding an explicit contract. On Wednesday, July 2, 2003, at 02:16 PM, Jason Carreira wrote: This is a concern that Mike expressed as well, but I challenged him to look at the code and see if it really makes sense. He looked, and grudgingly agreed that it made sense to get rid of it, especially since it took like 10 minutes and Gavin from Hibernate was there, talking about how he'd removed the Peristable interface from Hibernate because it was just useless. Giving people a warm fuzzy feeling is not enough justification, IMO, to needlessly tie Actions to Xwork, when they can really just be POJO's with no-arg methods returning a String. Jason -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 12:01 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WebWork2, here I come! I agree completely. All this 'just define it/figure it out at runtime' stuff really bothers me. Interfaces might be very 'old school' now, but they are useful, just so you know at compile time what contracts your components/classes/whatever are adhering to. I still have yet to look at xwork (waiting for migration guides+tools and performance reports), but the concept of having all information in an xml file and an active effort to remove type safety/contracts from code feels very wrong. I understand the allure of 'but you can use ANYTHING as an action!', but I do feel that those things that are used as an action should anticipate somewhat that they are one and will be treated as one, in most cases. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/ 01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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 agree, and I haven't looked at CVS lately, but if the Action interface is gone I'd like for it to be put back so that we can discuss this more. I think the mistake in your logic is that an action is a just a POJO. It's NOT though, it's a POJO with a method called execute() that contains a stuff. That stuff is specifically put in the execute() method because that object needs to be recognized as something more than just an object: it HAS an execute() method, and therefore it IS an Action. This is a identity has been used by OO for decades and there is no reason we should get rid of it now. The argument that making your object implement Action ties it to XWork is dumb. So what if it is... even without it, having a method called execute() ties it to XWork anyway. Even having support for any method (a la command pattern), it is still tied to XWork because the action was written to operate in certain ways (IoC pattern support, getters and setters, and possible callouts to ActionContext). Please don't underestimate the importance of compile-time checking. For some things (validation, type coercion, web layers, etc) using runtime features of the language is very nice. But I don't want everything to be runtime -- that's why I choose WebWork: it provides a nice balance between compile time and runtime typing. I vote a BIG -1 to removing the Action interface, I have yet to see a real use case that would demonstrate the importance of doing this. -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 11:16 AM Subject: RE: [OS-webwork] WebWork2, here I come! This is a concern that Mike expressed as well, but I challenged him to look at the code and see if it really makes sense. He looked, and grudgingly agreed that it made sense to get rid of it, especially since it took like 10 minutes and Gavin from Hibernate was there, talking about how he'd removed the Peristable interface from Hibernate because it was just useless. Giving people a warm fuzzy feeling is not enough justification, IMO, to needlessly tie Actions to Xwork, when they can really just be POJO's with no-arg methods returning a String. Jason -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 12:01 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WebWork2, here I come! I agree completely. All this 'just define it/figure it out at runtime' stuff really bothers me. Interfaces might be very 'old school' now, but they are useful, just so you know at compile time what contracts your components/classes/whatever are adhering to. I still have yet to look at xwork (waiting for migration guides+tools and performance reports), but the concept of having all information in an xml file and an active effort to remove type safety/contracts from code feels very wrong. I understand the allure of 'but you can use ANYTHING as an action!', but I do feel that those things that are used as an action should anticipate somewhat that they are one and will be treated as one, in most cases. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/ direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/ 01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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 String[]{password});
ActionProxy proxy = ActionProxyFactory.getFactory().
createActionProxy(/member, login, extraContext, false);
String result = proxy.execute();
assertEquals(Action.SUCCESS, result);
LoginAction action = (LoginAction)proxy.geAction();
// do more assertions here
}
Programmable ActionProxy is really awesome! Combined with a custom
ConfigurationProvider object you can test the action very easily, you
can just enable the ValidationInterceptor for example and easily unit
test all your externalized validation.xml settings too!
We created an abstract base class for all xwork tests. It configures an
ActionProxy object. ValidationInterceptor is added to the list of
interceptors and a MockResult is installed as the only result type.
public abstract class AbstractXWorkTest extends TestCase
{
private ActionProxy proxy;
private Class actionClass;
public AbstractXWorkTest( Class actionClass )
{
this.actionClass = actionClass;
}
protected void setUp() throws Exception
{
setUp(actionClass, actionClass.getName(), null);
}
/**
* Use this method if you want to setup this test with a specific
action class and method.
*
* This will throw out all previous configuration done by the normal
setUp() method.
*/
protected void setUp(Class clazz, String alias, String method)
throws Exception
{
ConfigurationManager.addConfigurationProvider(
createConfigurationProvider( method, alias ) );
ConfigurationManager.getConfiguration().reload();
proxy = ActionProxy.createActionProxy( , alias, new HashMap()
);
}
protected TestConfigurationProvider createConfigurationProvider(
String method, String alias )
{
return new TestConfigurationProvider(method, alias);
}
protected void tearDown() throws Exception
{
ConfigurationManager.clearConfigurationProviders();
super.tearDown();
}
protected Action getAction()
{
return proxy.getAction();
}
protected ActionProxy getActionProxy()
{
return proxy;
}
protected class TestConfigurationProvider implements
ConfigurationProvider
{
private String methodName;
private String alias;
public TestConfigurationProvider(String methodName, String
alias)
{
this.methodName = methodName;
this.alias = alias;
}
public void init( Configuration config )
{
PackageConfig defaultPackageConfig = new PackageConfig();
HashMap results = createResultTypes();
List interceptors = createInterceptors();
ActionConfig fooActionConfig = new ActionConfig( methodName,
actionClass, new HashMap(), results, interceptors );
defaultPackageConfig.addActionConfig( alias, fooActionConfig
);
config.addPackageConfig( defaultPackage,
defaultPackageConfig );
}
protected HashMap createResultTypes()
{
HashMap results = new HashMap();
ResultConfig resultConfig = new ResultConfig(
def-result-type, MockResult.class, new HashMap() );
results.put( Action.SUCCESS, resultConfig );
return results;
}
protected List createInterceptors()
{
List interceptors = new ArrayList();
interceptors.add( new ValidationInterceptor() );
return interceptors;
}
public void destroy()
{
}
public boolean needsReload()
{
return false;
}
}
}
Just do this to test a TestCreatePageAction derived test case do
something like this:
assertEquals( Action.SUCCESS, getActionProxy().execute() );
assertEquals( 1, getCreatePageAction().getActionErrors().size() );
assertEquals( getCreatePageAction().getText( space.key.empty ),
getCreatePageAction().getActionErrors().iterator().next() );
assertEquals( 0, getCreatePageAction().getFieldErrors().size() );
That's it. Hope it was useful for those who were thinking about unit
testing their xwork action classes :-)
Ara.
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored
Re: [OS-webwork] WebWork2, here I come!
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 PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 11:42 AM Subject: RE: [OS-webwork] WebWork2, here I come! But it doesn't HAVE to have an execute() method! Well, with the interface it does, but you don't have to USE it because you can specify the method to be called... Which is why the Interface is not needed. I doubt, though, that Mike has checked this in yet, even with his crazy Aussie sensibilities :-) (plus the fact that sf.net CVS is down evert time I try to get there). Actually, having a method called execute() does not tie you to Xwork... I think every Ant task has to have that, doesn't it? But it's not an interface, there. I've gone over my reasons for getting rid of the Action Interface... I'll let Mike chime in when he gets a minute on his crazy whirlwind trip :-) Jason -Original Message- From: Pat Lightbody [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 2:32 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WebWork2, here I come! I don't agree, and I haven't looked at CVS lately, but if the Action interface is gone I'd like for it to be put back so that we can discuss this more. I think the mistake in your logic is that an action is a just a POJO. It's NOT though, it's a POJO with a method called execute() that contains a stuff. That stuff is specifically put in the execute() method because that object needs to be recognized as something more than just an object: it HAS an execute() method, and therefore it IS an Action. This is a identity has been used by OO for decades and there is no reason we should get rid of it now. The argument that making your object implement Action ties it to XWork is dumb. So what if it is... even without it, having a method called execute() ties it to XWork anyway. Even having support for any method (a la command pattern), it is still tied to XWork because the action was written to operate in certain ways (IoC pattern support, getters and setters, and possible callouts to ActionContext). Please don't underestimate the importance of compile-time checking. For some things (validation, type coercion, web layers, etc) using runtime features of the language is very nice. But I don't want everything to be runtime -- that's why I choose WebWork: it provides a nice balance between compile time and runtime typing. I vote a BIG -1 to removing the Action interface, I have yet to see a real use case that would demonstrate the importance of doing this. -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 11:16 AM Subject: RE: [OS-webwork] WebWork2, here I come! This is a concern that Mike expressed as well, but I challenged him to look at the code and see if it really makes sense. He looked, and grudgingly agreed that it made sense to get rid of it, especially since it took like 10 minutes and Gavin from Hibernate was there, talking about how he'd removed the Peristable interface from Hibernate because it was just useless. Giving people a warm fuzzy feeling is not enough justification, IMO, to needlessly tie Actions to Xwork, when they can really just be POJO's with no-arg methods returning a String. Jason -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 12:01 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WebWork2, here I come! I agree completely. All this 'just define it/figure it out at runtime' stuff really bothers me. Interfaces might be very 'old school' now, but they are useful, just so you know at compile time what contracts your components/classes/whatever are adhering to. I still have yet to look at xwork (waiting for migration guides+tools and performance reports), but the concept of having all information in an xml file and an active effort to remove type safety/contracts from code feels very wrong. I understand the allure of 'but you can use ANYTHING as an action!', but I do feel that those things that are used as an action should anticipate somewhat that they are one and will be treated as one, in most cases. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click- url.com/go/psa0016ave/direct
Re: [OS-webwork] WebWork2, here I come!
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). Likewise, at one point XWork Are you sure about this? I'm looking at LifecyclePicoContainer and its test cases and it certainly looks like Components actively declare themselves as Startable, Stopable, and Disposable. M --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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 trying to guess the starting point or i need to go riffling through the xwork.xml to figure out where the starting point is. This is Not A Good Thing (tm). M Jason Carreira wrote: But it doesn't HAVE to have an execute() method! Well, with the interface it does, but you don't have to USE it because you can specify the method to be called... Which is why the Interface is not needed. I doubt, though, that Mike has checked this in yet, even with his crazy Aussie sensibilities :-) (plus the fact that sf.net CVS is down evert time I try to get there). Actually, having a method called execute() does not tie you to Xwork... I think every Ant task has to have that, doesn't it? But it's not an interface, there. I've gone over my reasons for getting rid of the Action Interface... I'll let Mike chime in when he gets a minute on his crazy whirlwind trip :-) Jason -Original Message- From: Pat Lightbody [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 2:32 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WebWork2, here I come! I don't agree, and I haven't looked at CVS lately, but if the Action interface is gone I'd like for it to be put back so that we can discuss this more. I think the mistake in your logic is that an action is a just a POJO. It's NOT though, it's a POJO with a method called execute() that contains a stuff. That stuff is specifically put in the execute() method because that object needs to be recognized as something more than just an object: it HAS an execute() method, and therefore it IS an Action. This is a identity has been used by OO for decades and there is no reason we should get rid of it now. The argument that making your object implement Action ties it to XWork is dumb. So what if it is... even without it, having a method called execute() ties it to XWork anyway. Even having support for any method (a la command pattern), it is still tied to XWork because the action was written to operate in certain ways (IoC pattern support, getters and setters, and possible callouts to ActionContext). Please don't underestimate the importance of compile-time checking. For some things (validation, type coercion, web layers, etc) using runtime features of the language is very nice. But I don't want everything to be runtime -- that's why I choose WebWork: it provides a nice balance between compile time and runtime typing. I vote a BIG -1 to removing the Action interface, I have yet to see a real use case that would demonstrate the importance of doing this. -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 11:16 AM Subject: RE: [OS-webwork] WebWork2, here I come! This is a concern that Mike expressed as well, but I challenged him to look at the code and see if it really makes sense. He looked, and grudgingly agreed that it made sense to get rid of it, especially since it took like 10 minutes and Gavin from Hibernate was there, talking about how he'd removed the Peristable interface from Hibernate because it was just useless. Giving people a warm fuzzy feeling is not enough justification, IMO, to needlessly tie Actions to Xwork, when they can really just be POJO's with no-arg methods returning a String. Jason -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 12:01 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WebWork2, here I come! I agree completely. All this 'just define it/figure it out at runtime' stuff really bothers me. Interfaces might be very 'old school' now, but they are useful, just so you know at compile time what contracts your components/classes/whatever are adhering to. I still have yet to look at xwork (waiting for migration guides+tools and performance reports), but the concept of having all information in an xml file and an active effort to remove type safety/contracts from code feels very wrong. I understand the allure of 'but you can use ANYTHING as an action!', but I do feel that those things that are used as an action should anticipate somewhat that they are one and will be treated as one, in most cases. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click- url.com/go/psa0016ave/direct;at.asp_061203_01/ 01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo
Re: [OS-webwork] WebWork2, here I come!
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 are a good thing. What is
the benefit to having multiple execute-like signature methods in an
Action and specifying which one to call in the config file? Why not
just have multiple Action implementing classes and put the heart in the
execute() method? Having an Action interface when the underlying
execution code ignores it or can invoke other methods doesn't seem
right either. Either the Action interface should go, or the ability to
execute any method should go. If you need to dispatch, you could do
that within your execute() method based on some outside parameter
coming in.
The analogy to Ant has come up. While its *cool* that you create an
Ant task by simply having a Java class with
public void execute() { ... }
it also makes things kludgier in other ways. I wish there was a
Taskable (Task is taken as a base class) interface in Ant with that
signature, personally. It just seems cleaner, clearer and just the
Java way of doing things.
I haven't seen any votes on this list yet, and maybe the Apache style
voting is not culture here, but +1 :) from me to keep Action and remove
the ability to execute other methods through reflection, for whatever
that is worth.
Erik
On Wednesday, July 2, 2003, at 02:32 PM, Pat Lightbody wrote:
I think the mistake in your logic is that an action is a just a
POJO. It's
NOT though, it's a POJO with a method called execute() that contains a
stuff. That stuff is specifically put in the execute() method
because that
object needs to be recognized as something more than just an object:
it
HAS an execute() method, and therefore it IS an Action. This is a
identity
has been used by OO for decades and there is no reason we should get
rid of
it now.
The argument that making your object implement Action ties it to XWork
is
dumb. So what if it is... even without it, having a method called
execute()
ties it to XWork anyway. Even having support for any method (a la
command
pattern), it is still tied to XWork because the action was written to
operate in certain ways (IoC pattern support, getters and setters, and
possible callouts to ActionContext).
Please don't underestimate the importance of compile-time checking.
For some
things (validation, type coercion, web layers, etc) using runtime
features
of the language is very nice. But I don't want everything to be
runtime --
that's why I choose WebWork: it provides a nice balance between
compile time
and runtime typing.
I vote a BIG -1 to removing the Action interface, I have yet to see a
real
use case that would demonstrate the importance of doing this.
-Pat
- Original Message -
From: Jason Carreira [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 11:16 AM
Subject: RE: [OS-webwork] WebWork2, here I come!
This is a concern that Mike expressed as well, but I challenged him to
look at the code and see if it really makes sense. He looked, and
grudgingly agreed that it made sense to get rid of it, especially
since
it took like 10 minutes and Gavin from Hibernate was there, talking
about how he'd removed the Peristable interface from Hibernate because
it was just useless.
Giving people a warm fuzzy feeling is not enough justification, IMO,
to
needlessly tie Actions to Xwork, when they can really just be POJO's
with no-arg methods returning a String.
Jason
-Original Message-
From: Hani Suleiman [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 12:01 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWork2, here I come!
I agree completely. All this 'just define it/figure it out at
runtime'
stuff really bothers me. Interfaces might be very 'old
school' now, but
they are useful, just so you know at compile time what
contracts your
components/classes/whatever are adhering to. I still have yet
to look
at xwork (waiting for migration guides+tools and performance
reports),
but the concept of having all information in an xml file and
an active
effort to remove type safety/contracts from code feels very wrong. I
understand the allure of 'but you can use ANYTHING as an
action!', but
I do feel that those things that are used as an action should
anticipate somewhat that they are one and will be treated as one, in
most cases.
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/
direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
RE: [OS-webwork] WebWork2, here I come!
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] Behalf Of Jason Carreira Sent: Wednesday, July 02, 2003 2:42 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] WebWork2, here I come! But it doesn't HAVE to have an execute() method! Well, with the interface it does, but you don't have to USE it because you can specify the method to be called... Which is why the Interface is not needed. I doubt, though, that Mike has checked this in yet, even with his crazy Aussie sensibilities :-) (plus the fact that sf.net CVS is down evert time I try to get there). Actually, having a method called execute() does not tie you to Xwork... I think every Ant task has to have that, doesn't it? But it's not an interface, there. I've gone over my reasons for getting rid of the Action Interface... I'll let Mike chime in when he gets a minute on his crazy whirlwind trip :-) Jason -Original Message- From: Pat Lightbody [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 2:32 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WebWork2, here I come! I don't agree, and I haven't looked at CVS lately, but if the Action interface is gone I'd like for it to be put back so that we can discuss this more. I think the mistake in your logic is that an action is a just a POJO. It's NOT though, it's a POJO with a method called execute() that contains a stuff. That stuff is specifically put in the execute() method because that object needs to be recognized as something more than just an object: it HAS an execute() method, and therefore it IS an Action. This is a identity has been used by OO for decades and there is no reason we should get rid of it now. The argument that making your object implement Action ties it to XWork is dumb. So what if it is... even without it, having a method called execute() ties it to XWork anyway. Even having support for any method (a la command pattern), it is still tied to XWork because the action was written to operate in certain ways (IoC pattern support, getters and setters, and possible callouts to ActionContext). Please don't underestimate the importance of compile-time checking. For some things (validation, type coercion, web layers, etc) using runtime features of the language is very nice. But I don't want everything to be runtime -- that's why I choose WebWork: it provides a nice balance between compile time and runtime typing. I vote a BIG -1 to removing the Action interface, I have yet to see a real use case that would demonstrate the importance of doing this. -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 11:16 AM Subject: RE: [OS-webwork] WebWork2, here I come! This is a concern that Mike expressed as well, but I challenged him to look at the code and see if it really makes sense. He looked, and grudgingly agreed that it made sense to get rid of it, especially since it took like 10 minutes and Gavin from Hibernate was there, talking about how he'd removed the Peristable interface from Hibernate because it was just useless. Giving people a warm fuzzy feeling is not enough justification, IMO, to needlessly tie Actions to Xwork, when they can really just be POJO's with no-arg methods returning a String. Jason -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 12:01 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WebWork2, here I come! I agree completely. All this 'just define it/figure it out at runtime' stuff really bothers me. Interfaces might be very 'old school' now, but they are useful, just so you know at compile time what contracts your components/classes/whatever are adhering to. I still have yet to look at xwork (waiting for migration guides+tools and performance reports), but the concept of having all information in an xml file and an active effort to remove type safety/contracts from code feels very wrong. I understand the allure of 'but you can use ANYTHING as an action!', but I do feel that those things that are used as an action should anticipate somewhat that they are one and will be treated as one, in most cases. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click- url.com/go/psa0016ave/direct
Re: [OS-webwork] WebWork2, here I come!
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 either creating class hierarchies to share this
state or passing special parameters to allow a larger grained action
to dispatch within itself, like the way ActionSupport did in WW1.x, or
they do BOTH. The ability to map aliases to entry point methods is
VERY useful for some people, myself included.
You extend from ActionSupport generally? Or Action?
Just for fun I coded this up:
public class DispatchAction implements Action {
private String method;
final public void setMethod(String method) {
this.method = method;
}
final public String execute() throws Exception {
System.out.println(invoke: + method);
return SUCCESS;
}
}
Of course just substitute the right reflection voodoo in execute() to
call whatever method you want. I'd make this abstract, of course, and
that is why I made the two methods final. In xwork.xml I set param
name=methodsomeMethod/param and have the static interceptor
configured. With the dynamic param interceptor also in the stack I was
able to switch the method from ?method=blah too.
What is wrong with that approach with how you want things to work?
Just because of subclassing?
Erik still +1 on Action, with no other entry points :)
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] WebWork2, here I come!
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 actions, but I
want the ability to use it to keep from having a proliferation of Action
classes.
Jason
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 4:17 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWork2, here I come!
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 either creating class hierarchies to share this
state or passing special parameters to allow a larger
grained action
to dispatch within itself, like the way ActionSupport did
in WW1.x, or
they do BOTH. The ability to map aliases to entry point methods is
VERY useful for some people, myself included.
You extend from ActionSupport generally? Or Action?
Just for fun I coded this up:
public class DispatchAction implements Action {
private String method;
final public void setMethod(String method) {
this.method = method;
}
final public String execute() throws Exception {
System.out.println(invoke: + method);
return SUCCESS;
}
}
Of course just substitute the right reflection voodoo in execute() to
call whatever method you want. I'd make this abstract, of
course, and
that is why I made the two methods final. In xwork.xml I set param
name=methodsomeMethod/param and have the static interceptor
configured. With the dynamic param interceptor also in the
stack I was
able to switch the method from ?method=blah too.
What is wrong with that approach with how you want things to work?
Just because of subclassing?
Erik still +1 on Action, with no other entry points :)
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites
including Data Reports, E-commerce, Portals, and Forums are
available now. Download today and enter to win an XBOX or
Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_06
1203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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 ugly. This could be prevented with a different interceptor than the Parameter one, or some other interceptor facility to keep ?method=xyz from switching things. People can choose not to use different methods on their actions, but I want the ability to use it to keep from having a proliferation of Action classes. Its just one DispatchAction though. Where is the proliferation? Subclass that and have at it with all the dynamic entry points you want. I'm still not seeing the drawback to this for you. I think keeping the Action interface tight, yet allowing implementors to do their own thing if they desire gives us the best of both worlds. Why should the framework itself accommodate this type of dynamic dispatching for you? I'm still not sold. But I'm still listening and *learning*. Erik --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] WebWork2, here I come!
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 the command param in WW1.x would cause doDefault()
to be called) or when you're trying to set it at runtime with a method
param, either of which allows the user to change the URL to change
behavior.
-Original Message-
From: Anthony Eden [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 4:45 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWork2, here I come!
So you're saying that setting a parameter via the URL and setting a
parameter via the xwork configuration file call the same
methods. This
sounds like a potential security hole for unsuspecting developers.
FWIW, JPublish allows you to pass configuration data to
actions in the
same way that you can with xwork.xml params, but this is a different
mechanism than using HTTP parameters. It doesn't call get and set
methods on the action rather there is a predefined method
loadConfiguration(). Not sure whether its better or worse,
just giving
an alternative solution to a similar problem.
Sincerely,
Anthony Eden
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 ugly.
People can choose not to use different methods on their
actions, but I
want the ability to use it to keep from having a proliferation of
Action classes.
Jason
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 4:17 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWork2, here I come!
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 either creating class hierarchies to share this
state or passing special parameters to allow a larger
grained action
to dispatch within itself, like the way ActionSupport did
in WW1.x, or
they do BOTH. The ability to map aliases to entry point methods is
VERY useful for some people, myself included.
You extend from ActionSupport generally? Or Action?
Just for fun I coded this up:
public class DispatchAction implements Action {
private String method;
final public void setMethod(String method) {
this.method = method;
}
final public String execute() throws Exception {
System.out.println(invoke: + method);
return SUCCESS;
}
}
Of course just substitute the right reflection voodoo in
execute() to
call whatever method you want. I'd make this abstract, of
course, and
that is why I made the two methods final. In xwork.xml I
set param
name=methodsomeMethod/param and have the static interceptor
configured. With the dynamic param interceptor also in the
stack I was
able to switch the method from ?method=blah too.
What is wrong with that approach with how you want things to work?
Just because of subclassing?
Erik still +1 on Action, with no other entry points :)
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites
including Data Reports, E-commerce, Portals, and Forums are
available now. Download today and enter to win an XBOX or
Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_06
1203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET
sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-
url.com/go/psa0016ave/direct;at.asp_061203_01/
01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites
including Data Reports, E-commerce, Portals, and Forums are
available now. Download today and enter to win an XBOX or
Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_06
1203_01/01
Re: [OS-webwork] WebWork2, here I come!
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 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 agree, and I haven't looked at CVS lately, but if the Action interface is gone I'd like for it to be put back so that we can discuss this more. I think the mistake in your logic is that an action is a just a POJO. It's NOT though, it's a POJO with a method called execute() that contains a stuff. That stuff is specifically put in the execute() method because that object needs to be recognized as something more than just an object: it HAS an execute() method, and therefore it IS an Action. This is a identity has been used by OO for decades and there is no reason we should get rid of it now. The argument that making your object implement Action ties it to XWork is dumb. So what if it is... even without it, having a method called execute() ties it to XWork anyway. Even having support for any method (a la command pattern), it is still tied to XWork because the action was written to operate in certain ways (IoC pattern support, getters and setters, and possible callouts to ActionContext). Please don't underestimate the importance of compile-time checking. For some things (validation, type coercion, web layers, etc) using runtime features of the language is very nice. But I don't want everything to be runtime -- that's why I choose WebWork: it provides a nice balance between compile time and runtime typing. I vote a BIG -1 to removing the Action interface, I have yet to see a real use case that would demonstrate the importance of doing this. -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 11:16 AM Subject: RE: [OS-webwork] WebWork2, here I come! This is a concern that Mike expressed as well, but I challenged him to look at the code and see if it really makes sense. He looked, and grudgingly agreed that it made sense to get rid of it, especially since it took like 10 minutes and Gavin from Hibernate was there, talking about how he'd removed the Peristable interface from Hibernate because it was just useless. Giving people a warm fuzzy feeling is not enough justification, IMO, to needlessly tie Actions to Xwork, when they can really just be POJO's with no-arg methods returning a String. Jason -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 12:01 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WebWork2, here I come! I agree completely. All this 'just define it/figure it out at runtime' stuff really bothers me. Interfaces might be very 'old school' now, but they are useful, just so you know at compile time what contracts your components/classes/whatever are adhering to. I still have yet to look at xwork (waiting for migration guides+tools and performance reports), but the concept of having all information in an xml file and an active effort to remove type safety/contracts from code feels very wrong. I understand the allure of 'but you can use ANYTHING as an action!', but I do feel that those things that are used as an action should anticipate somewhat that they are one and will be treated as one, in most cases. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/ direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/ 01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
RE: [OS-webwork] WebWork2, here I come!
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... This is in there for the same reason IoC is in Xwork. These are different styles of programming that have proven to be valuable, so they are supported in the core framework. If you have multiple buttons on a page that do different things, do you really want to have n different commands for it all extending from a common base class? There are other patterns of use that can be implemented with Interceptors and class hierarchies as well, and if they prove to be valuable, they'll be incorporated into the core framework as well. Jason -Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 4:51 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WebWork2, here I come! 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 ugly. This could be prevented with a different interceptor than the Parameter one, or some other interceptor facility to keep ?method=xyz from switching things. People can choose not to use different methods on their actions, but I want the ability to use it to keep from having a proliferation of Action classes. Its just one DispatchAction though. Where is the proliferation? Subclass that and have at it with all the dynamic entry points you want. I'm still not seeing the drawback to this for you. I think keeping the Action interface tight, yet allowing implementors to do their own thing if they desire gives us the best of both worlds. Why should the framework itself accommodate this type of dynamic dispatching for you? I'm still not sold. But I'm still listening and *learning*. Erik --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_06 1203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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
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 the command param in WW1.x would cause doDefault()
to be called) or when you're trying to set it at runtime with a method
param, either of which allows the user to change the URL to change
behavior.
-Original Message-
From: Anthony Eden [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 4:45 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWork2, here I come!
So you're saying that setting a parameter via the URL and setting a
parameter via the xwork configuration file call the same
methods. This
sounds like a potential security hole for unsuspecting developers.
FWIW, JPublish allows you to pass configuration data to
actions in the
same way that you can with xwork.xml params, but this is a different
mechanism than using HTTP parameters. It doesn't call get and set
methods on the action rather there is a predefined method
loadConfiguration(). Not sure whether its better or worse,
just giving
an alternative solution to a similar problem.
Sincerely,
Anthony Eden
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 ugly.
People can choose not to use different methods on their
actions, but I
want the ability to use it to keep from having a proliferation of
Action classes.
Jason
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 4:17 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWork2, here I come!
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 either creating class hierarchies to share this
state or passing special parameters to allow a larger
grained action
to dispatch within itself, like the way ActionSupport did
in WW1.x, or
they do BOTH. The ability to map aliases to entry point methods is
VERY useful for some people, myself included.
You extend from ActionSupport generally? Or Action?
Just for fun I coded this up:
public class DispatchAction implements Action {
private String method;
final public void setMethod(String method) {
this.method = method;
}
final public String execute() throws Exception {
System.out.println(invoke: + method);
return SUCCESS;
}
}
Of course just substitute the right reflection voodoo in
execute() to
call whatever method you want. I'd make this abstract, of
course, and
that is why I made the two methods final. In xwork.xml I
set param
name=methodsomeMethod/param and have the static interceptor
configured. With the dynamic param interceptor also in the
stack I was
able to switch the method from ?method=blah too.
What is wrong with that approach with how you want things to work?
Just because of subclassing?
Erik still +1 on Action, with no other entry points :)
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites
including Data Reports, E-commerce, Portals, and Forums are
available now. Download today and enter to win an XBOX or
Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_06
1203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET
sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-
url.com/go/psa0016ave/direct;at.asp_061203_01/
01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites
including Data Reports, E-commerce, Portals, and Forums are
available now. Download today and enter to win an XBOX or
Visual Studio .NET.
http://aspnet.click-url.com/go
RE: [OS-webwork] WebWork2, here I come!
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 Action, I'm for removing the execute() method and just making it default. Alias = action class + method name (default to execute()) Could it get simpler? Why pass URL parameters and all this crazy complicated stuff? M --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] WebWork2, here I come!
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: [OS-webwork] WebWork2, here I come!
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
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 the command param in WW1.x would cause
doDefault() to be called) or when you're trying to set it
at runtime
with a method param, either of which allows the user to
change the URL
to change behavior.
-Original Message-
From: Anthony Eden [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 4:45 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWork2, here I come!
So you're saying that setting a parameter via the URL and setting a
parameter via the xwork configuration file call the same
methods. This
sounds like a potential security hole for unsuspecting developers.
FWIW, JPublish allows you to pass configuration data to
actions in the
same way that you can with xwork.xml params, but this is a
different
mechanism than using HTTP parameters. It doesn't call get and set
methods on the action rather there is a predefined method
loadConfiguration(). Not sure whether its better or worse,
just giving
an alternative solution to a similar problem.
Sincerely,
Anthony Eden
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 ugly.
People can choose not to use different methods on their
actions, but I
want the ability to use it to keep from having a proliferation of
Action classes.
Jason
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 4:17 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWork2, here I come!
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 either creating class hierarchies to
share this
state or passing special parameters to allow a larger
grained action
to dispatch within itself, like the way ActionSupport did
in WW1.x, or
they do BOTH. The ability to map aliases to entry point
methods is
VERY useful for some people, myself included.
You extend from ActionSupport generally? Or Action?
Just for fun I coded this up:
public class DispatchAction implements Action {
private String method;
final public void setMethod(String method) {
this.method = method;
}
final public String execute() throws Exception {
System.out.println(invoke: + method);
return SUCCESS;
}
}
Of course just substitute the right reflection voodoo in
execute() to
call whatever method you want. I'd make this abstract, of
course, and
that is why I made the two methods final. In xwork.xml I
set param
name=methodsomeMethod/param and have the static interceptor
configured. With the dynamic param interceptor also in the
stack I was
able to switch the method from ?method=blah too.
What is wrong with that approach with how you want things
to work?
Just because of subclassing?
Erik still +1 on Action, with no other entry points :)
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites
including Data Reports, E-commerce, Portals, and Forums are
available now. Download today and enter to win an XBOX or Visual
Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_06
1203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET
sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET
RE: [OS-webwork] WebWork2, here I come!
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 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: [OS-webwork] WebWork2, here I come!
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
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 the command param in WW1.x would cause
doDefault() to be called) or when you're trying to set it
at runtime
with a method param, either of which allows the user to
change the URL
to change behavior.
-Original Message-
From: Anthony Eden [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 4:45 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWork2, here I come!
So you're saying that setting a parameter via the URL and
setting a
parameter via the xwork configuration file call the same
methods.
This sounds like a potential security hole for unsuspecting
developers.
FWIW, JPublish allows you to pass configuration data to
actions in
the same way that you can with xwork.xml params, but this is a
different
mechanism than using HTTP parameters. It doesn't call get and set
methods on the action rather there is a predefined method
loadConfiguration(). Not sure whether its better or worse,
just giving
an alternative solution to a similar problem.
Sincerely,
Anthony Eden
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 ugly.
People can choose not to use different methods on their
actions, but I
want the ability to use it to keep from having a
proliferation of
Action classes.
Jason
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 4:17 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWork2, here I come!
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 either creating class hierarchies to
share this
state or passing special parameters to allow a larger
grained action
to dispatch within itself, like the way ActionSupport did
in WW1.x, or
they do BOTH. The ability to map aliases to entry point
methods is
VERY useful for some people, myself included.
You extend from ActionSupport generally? Or Action?
Just for fun I coded this up:
public class DispatchAction implements Action {
private String method;
final public void setMethod(String method) {
this.method = method;
}
final public String execute() throws Exception {
System.out.println(invoke: + method);
return SUCCESS;
}
}
Of course just substitute the right reflection voodoo in
execute() to
call whatever method you want. I'd make this abstract,
of course,
and that is why I made the two methods final. In xwork.xml I
set param
name=methodsomeMethod/param and have the static
interceptor
configured. With the dynamic param interceptor also in
the stack
I was able to switch the method from ?method=blah too.
What is wrong with that approach with how you want things
to work?
Just because of subclassing?
Erik still +1 on Action, with no other entry
points :)
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites
including Data Reports, E-commerce, Portals, and Forums are
available now. Download today and enter to win an XBOX
or Visual
Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_06
Re: [OS-webwork] WebWork2, here I come!
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! -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 Action, I'm for removing the execute() method and just making it default. Alias = action class + method name (default to execute()) Could it get simpler? Why pass URL parameters and all this crazy complicated stuff? M --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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, here I come!
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: [OS-webwork] WebWork2, here I come!
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
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 the command param in WW1.x would cause
doDefault() to be called) or when you're trying to set it
at runtime
with a method param, either of which allows the user to
change the URL
to change behavior.
-Original Message-
From: Anthony Eden [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 4:45 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWork2, here I come!
So you're saying that setting a parameter via the URL and
setting a
parameter via the xwork configuration file call the same
methods.
This sounds like a potential security hole for unsuspecting
developers.
FWIW, JPublish allows you to pass configuration data to
actions in
the same way that you can with xwork.xml params, but this is a
different
mechanism than using HTTP parameters. It doesn't call get and set
methods on the action rather there is a predefined method
loadConfiguration(). Not sure whether its better or worse,
just giving
an alternative solution to a similar problem.
Sincerely,
Anthony Eden
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 ugly.
People can choose not to use different methods on their
actions, but I
want the ability to use it to keep from having a
proliferation of
Action classes.
Jason
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 4:17 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWork2, here I come!
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 either creating class hierarchies to
share this
state or passing special parameters to allow a larger
grained action
to dispatch within itself, like the way ActionSupport did
in WW1.x, or
they do BOTH. The ability to map aliases to entry point
methods is
VERY useful for some people, myself included.
You extend from ActionSupport generally? Or Action?
Just for fun I coded this up:
public class DispatchAction implements Action {
private String method;
final public void setMethod(String method) {
this.method = method;
}
final public String execute() throws Exception {
System.out.println(invoke: + method);
return SUCCESS;
}
}
Of course just substitute the right reflection voodoo in
execute() to
call whatever method you want. I'd make this abstract,
of course,
and that is why I made the two methods final. In xwork.xml I
set param
name=methodsomeMethod/param and have the static
interceptor
configured. With the dynamic param interceptor also in
the stack
I was able to switch the method from ?method=blah too.
What is wrong with that approach with how you want things
to work?
Just because of subclassing?
Erik still +1 on Action, with no other entry
points :)
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites
including Data Reports, E-commerce, Portals, and Forums are
available now. Download today and enter to win an XBOX
or Visual
Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_06
1203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET
sites including
Data
Re: [OS-webwork] WebWork2, here I come!
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 return type on those methods to Object.
From a terminology standpoint and for consistency, I think the Action
interface should retain the execute() method. Developers associate action
objects as implementing a specific interface and I think the framework
should leverage this association. And that to me implies that the
ActionSupport class should continue to implement the Action interface and
the associated execute() method.
Now bear with me.
Create a new class (or rename the BaseActionSupport) called CommandSupport
(for command driven actions mind you) that implements everything in the
current BaseActionSupport minus the Action interface. This class will be
subclassed by anyone wanting to declare their own execution methods while
providing all the validation/locale support existing in ActionSupport.
Then the only issue is the result types (success, error, etc) which could be
refactored into a separate interface that both ActionSupport and
CommandSupport implement. In the end you would probably have something like:
public interface ResultTypes {
// or another name that floats your boat
public static final String SUCCESS = success;
// etc
}
public interface Action {
public String execute() throws Exception;
}
public class CommandSupport implements ResultTypes, ValidationAware,
LocaleAware, Serializable {
}
public class ActionSupport extends CommandSupport implements Action {
}
This should give most people the flexibility to do what they want. Thoughts?
- Brock
// Make the simple things easy and the hard things possible.
- Original Message -
From: Matt Ho [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 5:11 PM
Subject: Re: [OS-webwork] WebWork2, here I come!
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!
-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 Action, I'm for removing the
execute() method and just making it default.
Alias = action class + method name (default to execute())
Could it get simpler? Why pass URL parameters and all this
crazy complicated stuff?
M
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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]) penned the words: 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! -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 Action, I'm for removing the execute() method and just making it default. Alias = action class + method name (default to execute()) Could it get simpler? Why pass URL parameters and all this crazy complicated stuff? M --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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 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 return type on those methods to Object.
From a terminology standpoint and for consistency, I think the Action
interface should retain the execute() method. Developers associate action
objects as implementing a specific interface and I think the framework
should leverage this association. And that to me implies that the
ActionSupport class should continue to implement the Action interface and
the associated execute() method.
Now bear with me.
Create a new class (or rename the BaseActionSupport) called CommandSupport
(for command driven actions mind you) that implements everything in the
current BaseActionSupport minus the Action interface. This class will be
subclassed by anyone wanting to declare their own execution methods while
providing all the validation/locale support existing in ActionSupport.
Then the only issue is the result types (success, error, etc) which could be
refactored into a separate interface that both ActionSupport and
CommandSupport implement. In the end you would probably have something like:
public interface ResultTypes {
// or another name that floats your boat
public static final String SUCCESS = success;
// etc
}
public interface Action {
public String execute() throws Exception;
}
public class CommandSupport implements ResultTypes, ValidationAware,
LocaleAware, Serializable {
}
public class ActionSupport extends CommandSupport implements Action {
}
This should give most people the flexibility to do what they want. Thoughts?
- Brock
// Make the simple things easy and the hard things possible.
- Original Message -
From: Matt Ho [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 5:11 PM
Subject: Re: [OS-webwork] WebWork2, here I come!
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!
-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 Action, I'm for removing the
execute() method and just making it default.
Alias = action class + method name (default to execute())
Could it get simpler? Why pass URL parameters and all this
crazy complicated stuff?
M
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
RE: [OS-webwork] WebWork2, here I come!
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 Of Jason Carreira Sent: Wednesday, July 02, 2003 5:20 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] WebWork2, here I come! 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 Action, I'm for removing the execute() method and just making it default. Alias = action class + method name (default to execute()) Could it get simpler? Why pass URL parameters and all this crazy complicated stuff? M --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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 PROTECTED]
Sent: Wednesday, July 02, 2003 5:57 PM
Subject: Re: [OS-webwork] WebWork2, here I come!
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 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 return type on those methods to Object.
From a terminology standpoint and for consistency, I think the Action
interface should retain the execute() method. Developers associate
action
objects as implementing a specific interface and I think the framework
should leverage this association. And that to me implies that the
ActionSupport class should continue to implement the Action interface
and
the associated execute() method.
Now bear with me.
Create a new class (or rename the BaseActionSupport) called
CommandSupport
(for command driven actions mind you) that implements everything in the
current BaseActionSupport minus the Action interface. This class will be
subclassed by anyone wanting to declare their own execution methods
while
providing all the validation/locale support existing in ActionSupport.
Then the only issue is the result types (success, error, etc) which
could be
refactored into a separate interface that both ActionSupport and
CommandSupport implement. In the end you would probably have something
like:
public interface ResultTypes {
// or another name that floats your boat
public static final String SUCCESS = success;
// etc
}
public interface Action {
public String execute() throws Exception;
}
public class CommandSupport implements ResultTypes, ValidationAware,
LocaleAware, Serializable {
}
public class ActionSupport extends CommandSupport implements Action {
}
This should give most people the flexibility to do what they want.
Thoughts?
- Brock
// Make the simple things easy and the hard things possible.
- Original Message -
From: Matt Ho [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 5:11 PM
Subject: Re: [OS-webwork] WebWork2, here I come!
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!
-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 Action, I'm for removing the
execute() method and just making it default.
Alias = action class + method name (default to execute())
Could it get simpler? Why pass URL parameters and all this
crazy complicated stuff?
M
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony
Re: [OS-webwork] WebWork2, here I come!
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 :)
It strikes me that if you want to combine the CRUD into a single class,
you could do it as follows. It's not a short as a single class, but I
think this is far easier to follow.
I can simply use ReservationAction.Create, ReservationAgent.Read, etc in
my xwork file as appropriate and the functionality of the class is a lot
more clear than it would be otherwise :)
public abstract class ReservationAction implements Action {
private ReservationAgent agent;
public ReservationAction(ReservationAgent agent) {
this.agent = agent;
// do other stuff
}
// do other stuff here
public static class Create extends ReservationAction {
public String execute() {
...
}
}
public static class Read extends ReservationAction {
public String execute() {
...
}
}
public static class Update extends ReservationAction {
public String execute() {
...
}
}
public static class Delete extends ReservationAction {
public String execute() {
...
}
}
}
The topic of workflow reminded me of struts discussions a while back on
the same topic. I don't think struts ever came up with a good solution,
but they never had an interceptor stack :)
I'm thinking aloud again ...
It strikes me that doExecute, doValidation, and doDefault could be
utilized by an interceptor to do all sorts of interestings.
* a view read only page- doExecute()
* an input/execute pair of pages would be doDefault - doValidation /
doExecute
* an input/confirm/execute trio would be doDefault - doValidation -
doValidation / doExecute
* a multipage form would be doDefault - doValidate(label) -
doValidate(anotherLabel) - doValidate()/doExcute()
ActionSupport could provide default empty implementations for
doExecute(), doValidate(), and doDefault(). ActionSupport would use a
WorkflowStrategy to figure out how to traverse the various pages.
Alternately, you could create an interface that had these method
signatures and embed the strategy in an interceptor.
However, methinks that this workflow stuff and non-concrete actions may
not mix well.
Thoughts?
M
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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 much time with Struts :) It strikes me that if you want to combine the CRUD into a single class, you could do it as follows. It's not a short as a single class, but I think this is far easier to follow. I don't see how this is easier to read than a doCreate() and doUpdate() method in an action? For my part, I think that retaining execute() on the interface is the best thing to do. Beginners docs can say 'all you need to do is implement Action'. More advanced docs can say 'if you want more than one command - extend actionsupport, and use the doX() methods'. The only time that you wouldn't use execute() is if you wanted more than one command. I don't want to read someone's webwork code, and try to work out where the entry point is. Just because we can do something doesn't mean that we should. From mike: Execute() is a best practice, not a necessity? I don't get the reason to remove it. Please give me an example of how removing this interface makes it easier. So, -1 on removing execute() from the interface. Scott -- ATLASSIAN - http://www.atlassian.com Expert J2EE Software, Services and Support --- Need a simple, powerful way to track and manage issues? Try JIRA - http://www.atlassian.com/software/jira --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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, email
etc).
For CRUD actions, I'd probably (with what I know of WW2 thus far), do
this:
abstract public class CrudAction implements Action {
final public void setOperation(String operation) { ... }
final public String execute() throws Exception {
// switch on operation value
}
abstract protected String create() throws Exception;
abstract protected String retrieve() throws Exception;
abstract protected String update() throws Exception;
abstract protected String delete() throws Exception;
}
Why do we need an Action to have multiple entry points? I still don't
get it. Having the framework lock it into a single entry point does
not prevent patterns of multiple entry point implementations.
I thought we were trying to get away from Struts... let's lose the do
prefix :))
Erik
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
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 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 to
pick on me?! :) (yes, I'm the original author of LookupDispatchAction
- which is designed to handle multiple submit buttons for a single
form). I never use LDA in my code, though it was written because a
very lame consultant was hard-coding button labels into Struts actions:
if (Add Item.equals(label)) { } // and so on
I had to do something to keep the codebase from becoming so fragile and
coupled with text labels. Our current app doesn't have forms with
multiple submit button paths - but its a scenario that needs to be
addressed certainly.
Seriously, being able to specify the method to call in the action
element is much more clear to me than setting a method param...
Sheesh! :)
So make the framework set parameters from the action element too!
Look at Ant's DynamicConfigurator interface for inspiration ;)
This is in there for the same reason IoC is in Xwork. These are
different styles of programming that have proven to be valuable, so
they
are supported in the core framework. If you have multiple buttons on a
page that do different things, do you really want to have n different
commands for it all extending from a common base class?
Absolutely not. Again, my vote here is to use a dispatching action
under the covers, with still a single point of entry from the webwork
side of things. I'm still eagerly tuning in to find convincing
arguments otherwise. This is a fun discussion, in fact. Amazing how
different views can be on what is a seemingly trivial issue.
There are other patterns of use that can be implemented with
Interceptors and class hierarchies as well, and if they prove to be
valuable, they'll be incorporated into the core framework as well.
Cool... in fact that is great.
My vote for a tight interface and contract with Action/execute stems
from my experience with Ant (and surely Struts in some way). Ant plays
extremely loose with datatypes/tasks and I think it would have been
better to have it tightened up there as well to make things more
explicit. It is quite cool what Ant does with introspection, though,
and it leads to rich expressiveness in types used in tasks... yet there
is still public void execute() as the single entry point for them all.
Erik
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] WebWork2, here I come!
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 - ModelDriven - Parameters (which calls getModel()) -Original Message- From: Matt Ho [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 6:12 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WebWork2, here I come! That just seems wrong :) Jason Carreira wrote: Or, you could apply the StaticParamInterceptor before ModelDriven and again after ParamInterceptor... --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] WebWork2, here I come!
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 though.. I like more descriptive names.
Jason
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 9:04 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWork2, here I come!
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, email
etc).
For CRUD actions, I'd probably (with what I know of WW2 thus far), do
this:
abstract public class CrudAction implements Action {
final public void setOperation(String operation) { ... }
final public String execute() throws Exception {
// switch on operation value
}
abstract protected String create() throws Exception;
abstract protected String retrieve() throws Exception;
abstract protected String update() throws Exception;
abstract protected String delete() throws Exception;
}
Why do we need an Action to have multiple entry points? I
still don't
get it. Having the framework lock it into a single entry point does
not prevent patterns of multiple entry point implementations.
I thought we were trying to get away from Struts... let's
lose the do
prefix :))
Erik
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites
including Data Reports, E-commerce, Portals, and Forums are
available now. Download today and enter to win an XBOX or
Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_06
1203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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. It's best done as a concrete class I think.
M
On 3/7/03 9:57 AM, Matt Ho ([EMAIL PROTECTED]) penned the words:
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 :)
It strikes me that if you want to combine the CRUD into a single class,
you could do it as follows. It's not a short as a single class, but I
think this is far easier to follow.
I can simply use ReservationAction.Create, ReservationAgent.Read, etc in
my xwork file as appropriate and the functionality of the class is a lot
more clear than it would be otherwise :)
public abstract class ReservationAction implements Action {
private ReservationAgent agent;
public ReservationAction(ReservationAgent agent) {
this.agent = agent;
// do other stuff
}
// do other stuff here
public static class Create extends ReservationAction {
public String execute() {
...
}
}
public static class Read extends ReservationAction {
public String execute() {
...
}
}
public static class Update extends ReservationAction {
public String execute() {
...
}
}
public static class Delete extends ReservationAction {
public String execute() {
...
}
}
}
The topic of workflow reminded me of struts discussions a while back on
the same topic. I don't think struts ever came up with a good solution,
but they never had an interceptor stack :)
I'm thinking aloud again ...
It strikes me that doExecute, doValidation, and doDefault could be
utilized by an interceptor to do all sorts of interestings.
* a view read only page- doExecute()
* an input/execute pair of pages would be doDefault - doValidation /
doExecute
* an input/confirm/execute trio would be doDefault - doValidation -
doValidation / doExecute
* a multipage form would be doDefault - doValidate(label) -
doValidate(anotherLabel) - doValidate()/doExcute()
ActionSupport could provide default empty implementations for
doExecute(), doValidate(), and doDefault(). ActionSupport would use a
WorkflowStrategy to figure out how to traverse the various pages.
Alternately, you could create an interface that had these method
signatures and embed the strategy in an interceptor.
However, methinks that this workflow stuff and non-concrete actions may
not mix well.
Thoughts?
M
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] WebWork2, here I come!
-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 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 to pick on me?! :) (yes, I'm the original author of LookupDispatchAction Heh :-) No. Just a lucky coincidence... Sheesh! :) So make the framework set parameters from the action element too! Look at Ant's DynamicConfigurator interface for inspiration ;) See, but there's the problem I had with WW1.x... You had configuration constructs for Commands, but the whole CommandDriven stuff was implemented in ActionSupport. This needs to be core in configuration, and it needs to be core in the framework. Absolutely not. Again, my vote here is to use a dispatching action under the covers, with still a single point of entry from the webwork side of things. I'm still eagerly tuning in to find convincing arguments otherwise. This is a fun discussion, in fact. Amazing how different views can be on what is a seemingly trivial issue. I'm still waiting to hear convincing arguments as to why I should change working code or why I'd want to use class hierarchies Having to subclass things is EXACTLY what I want to avoid... It was a huge hassle in WW1.x. There are other patterns of use that can be implemented with Interceptors and class hierarchies as well, and if they prove to be valuable, they'll be incorporated into the core framework as well. Cool... in fact that is great. My vote for a tight interface and contract with Action/execute stems from my experience with Ant (and surely Struts in some way). Ant plays extremely loose with datatypes/tasks and I think it would have been better to have it tightened up there as well to make things more explicit. It is quite cool what Ant does with introspection, though, and it leads to rich expressiveness in types used in tasks... yet there is still public void execute() as the single entry point for them all. Erik Well, this is not exactly the same. I don't want to be loose with data types or anything like that. Reflective method calls are a pretty well understood and low-risk technology. Jason --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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 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 though.. I like more descriptive names.
Jason
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 9:04 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWork2, here I come!
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, email
etc).
For CRUD actions, I'd probably (with what I know of WW2 thus far), do
this:
abstract public class CrudAction implements Action {
final public void setOperation(String operation) { ... }
final public String execute() throws Exception {
// switch on operation value
}
abstract protected String create() throws Exception;
abstract protected String retrieve() throws Exception;
abstract protected String update() throws Exception;
abstract protected String delete() throws Exception;
}
Why do we need an Action to have multiple entry points? I
still don't
get it. Having the framework lock it into a single entry point does
not prevent patterns of multiple entry point implementations.
I thought we were trying to get away from Struts... let's
lose the do
prefix :))
Erik
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites
including Data Reports, E-commerce, Portals, and Forums are
available now. Download today and enter to win an XBOX or
Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_06
1203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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 where our disagreement stems from. And as for your analysis of AS - exactly correct, except for the interceptor bit. It's best done as a concrete class I think. Yeah, I think I'd have to agree with you here. M --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
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 [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 6:47 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] WebWork2, here I come!
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
return type on those methods to Object.
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 ValidationAware, thus returning Object doesn't really
change much (ie you're still going to have to cast it).
From a terminology standpoint and for consistency, I think
the Action interface should retain the execute() method.
Developers associate action objects as implementing a
specific interface and I think the framework should leverage
this association. And that to me implies that the
ActionSupport class should continue to implement the Action
interface and the associated execute() method.
Now bear with me.
Create a new class (or rename the BaseActionSupport) called
CommandSupport (for command driven actions mind you) that
implements everything in the current BaseActionSupport minus
the Action interface. This class will be subclassed by anyone
wanting to declare their own execution methods while
providing all the validation/locale support existing in ActionSupport.
Then the only issue is the result types (success, error, etc)
which could be refactored into a separate interface that both
ActionSupport and CommandSupport implement. In the end you
would probably have something like:
public interface ResultTypes {
// or another name that floats your boat
public static final String SUCCESS = success;
// etc
}
public interface Action {
public String execute() throws Exception;
}
public class CommandSupport implements ResultTypes,
ValidationAware, LocaleAware, Serializable { }
public class ActionSupport extends CommandSupport implements
Action { }
This should give most people the flexibility to do what they
want. Thoughts?
- Brock
I don't see why we'd want to do this... If we don't remove the execute()
method, there's no reason to create a separate interface without it.
b: I thought that was the whole point?! You didn't want to tie your actions
explicitly to the execute() method. I'm all in favor of leaving the Action
class and ActionSupport as is! I was just suggesting a way to leverage the
code in ActionSupport without mandating the use of execute(). I agree with
your comment 100%.
Jason
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] WebWork2, here I come!
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 ValidationAware, thus returning Object doesn't really change much (ie you're still going to have to cast it). Sorry, I thought you were talking about the return type of execute() and other like methods... I don't see why we'd want to do this... If we don't remove the execute() method, there's no reason to create a separate interface without it. b: I thought that was the whole point?! You didn't want to tie your actions explicitly to the execute() method. I'm all in favor of leaving the Action class and ActionSupport as is! I was just suggesting a way to leverage the code in ActionSupport without mandating the use of execute(). I agree with your comment 100%. You showed 2 interfaces, one still containing the execute() method. If we're not getting rid of the Interface altogether, which is what I'm suggesting, then lets not just create another Interface. Jason --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] WebWork2, here I come!
I just wanted to drop a note that I'm almost a switcher to WW2. I've gotten my demo app that I use for all of my Ant, XDoclet, Lucene, and Struts presentations working just fine in WW2. Thanks to all that contributed to the wiki and sample app. where I learned enough to make it work. I'm on the process of plugging in validation, so I cannot comment on that yet. My app is a simple single-form and action with a simple String setter (think of a Google page, q=...). I do have a few initial questions to get myself rolling even further along to being a complete switcher: - How do I get to my application context attributes? I set some in an initialization servlet from its init-param's. - I plan on refactoring my infamous custom:label taglib in Struts to the comparable piece in WW2. Can someone point me in the right direction to grab the validation metadata so I can tell if a field is required or not, as well as getting at the errors from the validation so I can turn the label red? Or is there already infrastructure in place to make this unneeded or easier? Great work, everyone! WW2 passed the 15-minute rule of being able to pull it down and immediately be effective with it. There is still a way to go for me to fully implement all the pieces our current app can do (the main additional piece has to do with custom resource handling, not from a properties file but a DB instead). Perhaps at the next TheServerSide Symposium I'll do an Advanced WebWork presentation instead! :) (oops... Jason said he wanted that one, so its all his!). Erik p.s. I'm current on the list in digest mode, but will likely switch to individual messages as my WW2 usage cranks up. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] WebWork2, here I come!
Well, I'm glad to hear it But now you're making me work... See below... -Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 12:39 PM To: [EMAIL PROTECTED] Subject: [OS-webwork] WebWork2, here I come! I just wanted to drop a note that I'm almost a switcher to WW2. I've gotten my demo app that I use for all of my Ant, XDoclet, Lucene, and Struts presentations working just fine in WW2. Thanks to all that contributed to the wiki and sample app. where I learned enough to make it work. I'm on the process of plugging in validation, so I cannot comment on that yet. My app is a simple single-form and action with a simple String setter (think of a Google page, q=...). I do have a few initial questions to get myself rolling even further along to being a complete switcher: - How do I get to my application context attributes? I set some in an initialization servlet from its init-param's. Check out ServletActionContext.getServletContext(). This should let you do what you want to do (at the expense of not being able to use your Action outside a Servlet container, but you're used to Struts, so we forgive you :-)) - I plan on refactoring my infamous custom:label taglib in Struts to the comparable piece in WW2. Can someone point me in the right direction to grab the validation metadata so I can tell if a field is required or not, as well as getting at the errors from the validation so I can turn the label red? Or is there already infrastructure in place to make this unneeded or easier? It's very easy to check for errors. If your Action implements ValidationAware (or extends ActionSupport or BaseActionSupport) then this is built in, as errors will be added to your action and you can use hasErrors(), hasActionErrors(), hasFieldErrors(), getActionErrors(), and getFieldErrors() depending on what you need. For the validation metadata You can use ActionValidatorManager.getValidators(ActionInvocation invocation) to get them... You can get the ActionInvocation from the ActionContext. Unfortunately, this will return you a list of validators. You can check if they're FieldValidators and get the field name to compare... I realize this is not ideal for what I think you're trying to do. I'm open to changing / adding to make this easier, if you've got some ideas. The other challenge that you might face is if you want these tags to work when the page is rendered without coming through an Action... We've had some challenges there as far as not having an ActionInvocation yet. You'll probably also want to know not the validators on THIS alias, but the alias you're going to send the request TO. Yeah. Challenges. :-) Maybe we could work to make them work inside the Form tag, and have that have the ability to set the namespace and action alias for the sub-tags to access, then add another access method for looking up the validators using the namespace and alias to ActionValidatorManager. Great work, everyone! WW2 passed the 15-minute rule of being able to pull it down and immediately be effective with it. There is still a way to go for me to fully implement all the pieces our current app can do (the main additional piece has to do with custom resource handling, not from a properties file but a DB instead). This sounds cool... We could make resource loading pluggable, like we have for configuration, so message bundles can be pulled from other sources than just properties files. Perhaps at the next TheServerSide Symposium I'll do an Advanced WebWork presentation instead! :) (oops... Jason said he wanted that one, so its all his!). Heh :-) I think there's going to be lots to talk about Erik p.s. I'm current on the list in digest mode, but will likely switch to individual messages as my WW2 usage cranks up. We're just glad to have you... Next we'll convert Matt Raible, then we'll teach Craig McClanahan the error of his ways... LOL Jason --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
On Tuesday, July 1, 2003, at 04:52 PM, Jason Carreira wrote: We're just glad to have you... Next we'll convert Matt Raible, then we'll teach Craig McClanahan the error of his ways... LOL All that'd be left to do after that is get him to drop the devil-spawn abomination sometimes knows as JSF, and there might hope yet for the web portion of j2ee. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] WebWork2, here I come!
If you can give me XDoclet generation of the validations (server-side + client side) like Struts has, and provide Cactus integration like StrutsTestCase, I might be interested. Of course, then I'll have to learn SiteMesh over Tiles (or use Tiles with WW) and hope that WW supports indexed properties (I'm sure it does). Erik has defected... damn... ;-) Raible -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 2:57 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WebWork2, here I come! On Tuesday, July 1, 2003, at 04:52 PM, Jason Carreira wrote: We're just glad to have you... Next we'll convert Matt Raible, then we'll teach Craig McClanahan the error of his ways... LOL All that'd be left to do after that is get him to drop the devil-spawn abomination sometimes knows as JSF, and there might hope yet for the web portion of j2ee. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
Indexed properties is supposed, XDoclet could be added but the configuration is already damn easy without requiring XDoclet. Cactus integration is trivial, but why not just mock it all? -Pat - Original Message - From: Raible, Matt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 2:09 PM Subject: RE: [OS-webwork] WebWork2, here I come! If you can give me XDoclet generation of the validations (server-side + client side) like Struts has, and provide Cactus integration like StrutsTestCase, I might be interested. Of course, then I'll have to learn SiteMesh over Tiles (or use Tiles with WW) and hope that WW supports indexed properties (I'm sure it does). Erik has defected... damn... ;-) Raible -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 2:57 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WebWork2, here I come! On Tuesday, July 1, 2003, at 04:52 PM, Jason Carreira wrote: We're just glad to have you... Next we'll convert Matt Raible, then we'll teach Craig McClanahan the error of his ways... LOL All that'd be left to do after that is get him to drop the devil-spawn abomination sometimes knows as JSF, and there might hope yet for the web portion of j2ee. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] WebWork2, here I come!
That would be a good bileblog entry... Unfortunately, it's going to be a bad standard with lots of tool support... I'm still planning on putting at least the same kind of back-end integration with JSF that Craig put in for Struts. -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 4:57 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WebWork2, here I come! On Tuesday, July 1, 2003, at 04:52 PM, Jason Carreira wrote: We're just glad to have you... Next we'll convert Matt Raible, then we'll teach Craig McClanahan the error of his ways... LOL All that'd be left to do after that is get him to drop the devil-spawn abomination sometimes knows as JSF, and there might hope yet for the web portion of j2ee. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_06 1203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
Don't you worry about XDoclet generation of validations (and probably other pieces too, like parts of xwork.xml, why not call this webwork.xml since it is definitely tied to the web with references to JSP's??). Jason, and it seems Patrick, are not in favor of XDoclet much. XDoclet exists because folks choose to duplicate themselves all over the place, which is evil. With validations (and I'm not up to speed on the aliasing that is possible yet), we'll easily be able to generate those and I'll gladly create the module to do it after I do this stuff by hand a little and get familiar with all the pieces. With Struts, you end up with a form bean as a placeholder. With WW2, if you are presenting your model directly to the presentation from the actions it doesn't really make sense to tag validations on them but rather create a separate mapping by hand. But (and I still withhold judgment a bit on this), I like being able to display what the user typed in error for non-String fields. I'm vaguely thinking that some type of specialized interceptor could deal with this scenario though and keep all request fields in a Map and if validation fails, feed it back to the presentation when redisplaying the page. While typing that last sentence I realize its probably not easily possible though, except I think that OGNL has an interceptor hook too (thoughts on this anyone?). As for Cactus... screw Cactus! :) Its too slow and the beauty of WW2 is that actions aren't tied to container objects like HttpServletRequest. Mocking is the way to go. IoC rules. Actually Cactus still has its place. In our current app we use stateless session beans that have role-based security attached to them - testing these with Cactus will still be done. We had sparse coverage of our Struts code mainly because it was a pain to run tests for it (and our Struts actions were very thin proxies). Using WW2 will make it possible to boost our coverage up another tier. So Cactus makes sense to test the thin layer of container managed things and should be used to ensure that those interactions are working, although mock is always recommended until you actually need to verify the actual container. WW supporting indexed properties... ha! It uses OGNL and an object stack, not the weaker BeanUtils syntax. On this note though, please upgrade WW2 to the latest/newest OGNL release (I noticed Drew posted a note about it to the Tapestry list - it pays to keep tabs on all the frameworks! ;) I may be speaking too soon here as I've not given it a try, but I'd be way surprised if WW2 cannot do what Struts can do in this respect, and do it even better. As for me defecting... still remains to be seen if I defect my larger day job projects where Struts has momentum. I'm pragmatic and wouldn't switch gears without buy-in from all the other developers. But Struts has serious design flaws (and no, I didn't just discover it, I've known it all along). Tapestry is definitely on the radar, but even Howard Lewis-Ship admits that Tapestry code is hard to test. WW2 has a nice middle-ground in terms of web flexibilty and components (no question that Tapesty's web componentization is slick) and IoC/command/interceptor framework. I'm definitely going to give WW2 a good thorough try. Erik On Tuesday, July 1, 2003, at 05:09 PM, Raible, Matt wrote: If you can give me XDoclet generation of the validations (server-side + client side) like Struts has, and provide Cactus integration like StrutsTestCase, I might be interested. Of course, then I'll have to learn SiteMesh over Tiles (or use Tiles with WW) and hope that WW supports indexed properties (I'm sure it does). Erik has defected... damn... ;-) Raible -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 2:57 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WebWork2, here I come! On Tuesday, July 1, 2003, at 04:52 PM, Jason Carreira wrote: We're just glad to have you... Next we'll convert Matt Raible, then we'll teach Craig McClanahan the error of his ways... LOL All that'd be left to do after that is get him to drop the devil-spawn abomination sometimes knows as JSF, and there might hope yet for the web portion of j2ee. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/ 01 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E
Re: [OS-webwork] WebWork2, here I come!
On Tuesday, July 1, 2003, at 04:52 PM, Jason Carreira wrote:
Well, I'm glad to hear it But now you're making me work... See
below...
You seemed far too relaxed at TSS... time to make you sweat! :)
- How do I get to my application context attributes? I
set some in
an initialization servlet from its init-param's.
Check out ServletActionContext.getServletContext(). This should let you
do what you want to do (at the expense of not being able to use your
Action outside a Servlet container, but you're used to Struts, so we
forgive you :-))
Actually I'd want something more elegant, like something like this:
public void setAppConfig(AppConfig config) { ... }
Where an AppConfig object is in application scope. Can this be done
with components.xml like the session stuff is done? If so, then I'm
all set. Otherwise it seems to be trivial to add an interceptor to do
this.
Where in the code (yeah, I'm learning it fast, but pointers always
help) is the components.xml and session scope dealt with?
- I plan on refactoring my infamous custom:label taglib
in Struts
to the comparable piece in WW2. Can someone point me in the right
direction to grab the validation metadata so I can tell if a field is
required or not, as well as getting at the errors from the validation
so I can turn the label red? Or is there already infrastructure in
place to make this unneeded or easier?
It's very easy to check for errors. If your Action implements
ValidationAware (or extends ActionSupport or BaseActionSupport) then
this is built in, as errors will be added to your action and you can
use
hasErrors(), hasActionErrors(), hasFieldErrors(), getActionErrors(),
and
getFieldErrors() depending on what you need.
Cool... I discovered ActionSupport after I sent my original mail and
got it working with doExecute.
For the validation metadata You can use
ActionValidatorManager.getValidators(ActionInvocation invocation) to
get
them... You can get the ActionInvocation from the ActionContext.
Unfortunately, this will return you a list of validators. You can check
if they're FieldValidators and get the field name to compare... I
realize this is not ideal for what I think you're trying to do. I'm
open
to changing / adding to make this easier, if you've got some ideas.
I'll give it a whirl. Looks like it'll be easy enough to find out if a
field is required or not.
The other challenge that you might face is if you want these tags to
work when the page is rendered without coming through an Action...
I never do that kind of thing anyway. All JSP's are under WEB-INF and
proxied by an action in Struts, and I'd keep that same concept for WW2.
You'll probably also want to know not the validators on THIS alias, but
the alias you're going to send the request TO. Yeah. Challenges. :-)
Ok, so this is how you turn off validation when coming into a page, but
turn it on when coming out?
Great work, everyone! WW2 passed the 15-minute rule of being able to
pull it down and immediately be effective with it. There is still a
way to go for me to fully implement all the pieces our
current app can
do (the main additional piece has to do with custom resource
handling,
not from a properties file but a DB instead).
This sounds cool... We could make resource loading pluggable, like we
have for configuration, so message bundles can be pulled from other
sources than just properties files.
Definitely resource loading should be pluggable. Having resources
statically in a WAR always seemed odd to me with Struts. I don't know
how good the Commons Resource code is (yes, I recognize the
questionable quality of Jakarta stuff too guys, and take what is good
and bitch about what is bad!) but if its a decent enough abstraction,
then lets use it. If it sucks, then not. Thoughts on this?
We're just glad to have you... Next we'll convert Matt Raible, then
we'll teach Craig McClanahan the error of his ways... LOL
Matt we can convert, no problem!
Craig... no way. He created the abomination known as DynaActionForms,
lest you forget! :)
Erik
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] WebWork2, here I come!
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Actually I'd want something more elegant, like something like this:
public void setAppConfig(AppConfig config) { ... }
Where an AppConfig object is in application scope. Can this be done
with components.xml like the session stuff is done? If so, then I'm
all set. Otherwise it seems to be trivial to add an
interceptor to do
this.
Where in the code (yeah, I'm learning it fast, but pointers always
help) is the components.xml and session scope dealt with?
Check out the com.opensymphony.xwork.interceptor.component package under
Xwork.
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
validators are added to the action level validators (and superclass
validators, etc) to build up the whole list. In this way you can have
some validators for one alias, but not the other.
Definitely resource loading should be pluggable. Having resources
statically in a WAR always seemed odd to me with Struts. I
don't know
how good the Commons Resource code is (yes, I recognize the
questionable quality of Jakarta stuff too guys, and take what is good
and bitch about what is bad!) but if its a decent enough abstraction,
then lets use it. If it sucks, then not. Thoughts on this?
I'm open to this... What are its dependencies?
We're just glad to have you... Next we'll convert Matt Raible, then
we'll teach Craig McClanahan the error of his ways... LOL
Matt we can convert, no problem!
Craig... no way. He created the abomination known as
DynaActionForms,
lest you forget! :)
LOL! No one is beyond redemption!
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork2, here I come!
Pat Lightbody wrote:
Indexed properties is supposed, XDoclet could be added but the
configuration is already damn easy without requiring XDoclet. Cactus
integration is trivial, but why not just mock it all?
I completely agree. WebWork doesn't require you to use something like
StrutsTestCase and/or Cactus because it's not as strongly tied to the
web. Here's a short example that tests a fictious /member/login.action
snip
Map parameters;
Map extraContext;
public void setUp() {
parameters = new HashMap();
extraContext = new HashMap();
extraContext.put(ActionContext.PARAMETERS, parameters);
}
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 = proxy.execute();
assertEquals(Action.SUCCESS, result);
LoginAction action = (LoginAction)proxy.geAction();
// do more assertions here
}
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
