Personally, I agree with Patrick here. As someone who uses WW actions outside of the web scope - this sort of thing is extremely useful.
1. I don't mind if MY configuration file gets more complicated 2. I don't mind writing and maintaining a custom configuration loader to load that configuration file! 3. But I need the ability to 'plug in' the configuration loader (as I understand it) This is exactly the same as being able to plug in your own Configuration object to webwork as you can now (using webwork.properties) - that is fantastically useful because in JIRA we actually have webwork.properties loaded in the database, so you can change any property on the fly - and it is persisted. Webwork has always been infinitely configurable if you want it to be, it's part of the ethos! Basically - I agree with Maurice and Hani - and Patrick. Simplicity = good Power and flexibility = good We need to find the right balance - simple for new users, configurable for power users. Documented for all. A knee jerk 'we won't add this feature cause it adds complexity' is a bad reaction IMHO. -mike On 5/11/02 7:05 AM, "Patrick Lightbody" ([EMAIL PROTECTED]) penned the words: > >>> 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 ------------------------------------------------------- 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
