> >No, it's the same problem that we had in the past (before > >GenericDispatcher). The solution that was proposed is to use the > >redirect.action (when I get it working that is). And for 1.3 I think that's > >fine. > > > > > You lost me. What problem are you trying to solve? I had thought that > the factory attribute was invented to make it so that you didn't have to > parse the view URL to determine if it's an action or not.
Well partly. The thing is that when you do Foo.success=Bar.action, it is ambiguous and confusing. Half the people might expect a chain to happen, while the other half might expect a new Http request to be made to Bar.action. So at least some people are going to be surprised. > > >- allow the configuration (XMLActionConfiguration vs > >PropertiesConfiguration) to be specified in the global configuration, or > >default to PropertiesConfiguration if not given (so things stay simple, > >right?) > > > Oh, another configuration option. Have I left my feelings about these > unclear as well? But this would eliminate many configuration options as well. For instance, Matt had to introduce a config option to dictate which extension you were mapping your actions to (*.action or *.jsp) so that the redirect.action would work and not try to chain. And remember, this config option is optional. WebWork, like all of OpenSymphony, should strive for simplicity up front, but flexibility for power users. I don't see that being able to define your own configuration breaks your goal of keeping things simple, given that the configuration is optional. > > >- Change the configuration architecture so that the example I posted in my > >weblog is supported. This basically means that internally, "Foo!someCommand" > >means nothing. Instead, the configuration (again, this is internally) > >actually is generic enough like the config I gave in my weblog. Then > >PropertiesConfiguration can read views.properties like it always did, and > >translate "Foo!someCommand" as "the class is Foo and pass a property > >key/value pair of command=someCommand in before executing". > > > > > What you are calling properties are actually parameters and are no > different that you would use with the ActionTag. Maybe a param tag > could be useful to keep View URL's cleaned up, but you can specify > parameters in the View URL's today to be passed into your actions. Or > at least you could. Please tell me that hasn't gone away. Yes, you are right, it is very similar to <ww:param/>, except in this case we want to define it in our action declaration, not our code. This sovles the command stuff I mentioned above, but also (as mentioned in my blog), cases like if you had a PoolingAction, you could define what other actions go in the pool. As for view URLs, no, I don't believe that has changed. > > >Before you shoot it down as overly complex, remember that externally, things > >are as simple as always, but power users (like me) can write a better > >XMLConfiguration that takes advantage of the new, powerful, (internal) > >configuration architecture. > > > > > Kaboom! Down in flames. > > Look, I don't see you proposing any functionality that hasn't existed in > a different form for a long time. Functionality BTW, that didn't > require any special effort on the part of the end user (i.e. extra > configuration). Actually, my proposal adds a large ammount of functionality while still keeping configuration simple for the newbie or anyone else who wants things as simple as possible. The primary change I'm suggesting is that the internal configuration architecture be reworked to be specific to actions (currently it is a generic Object get(String) method) and that complete support for action configuration be built in to the configuration archicture. Sure, I can do "jasperTest.success=orderList.jasper?dataSource=orders" (as you mentioned in your last email), but that is nothing but a hack. What it is doing is taking advantage of Http-specific features (parameters in the GET string) and jamming it in to the configuration. We don't all use WebWork in servlet environment (just look at OSWorkflow's WebWorkExecutor). We could still keep views.properties the same way you have it now and let "jasperTest.success=orderList.jasper?dataSource=orders" work, but that really should translate to a more specific configuration architcture that is defined in my original blog post. I really hope you see my point. Maurice, I believe you and I actually see the world very much the same, but it's just that I haven't been explaining my reasonings for this as clearly as I should be able to. I've looked at the sources, I've looked a all the different users and usages of WebWork, I've understood your concerns about simplicity, and I'm very confident that this proposal satisfies everything. The main thing is that for WebWork to become generic (something we all agree is a good move), you've got to eventually move to a configuration architecture that allows you to move past HTTP semantics. And just to be perfectly clear, this change would have _zero_ effect on anyone. They could continue to use views.properties for the rest of their life, since PropertiesConfiguration would continue to be the default config choice. There would be no need to edit webwork.properties. BUT, users that demand more COULD (optionally, very important to remember) change the action configuration method, allowing them to plug in to the more powerful internal configuration schema that webwork needs to support. -Pat ------------------------------------------------------- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
