Bill, You are correct. My proposal isn't supporting two (or three or four) configuration options. It's actually saying, let's only support only one _active_ configuration mechanism. The current code uses both PropertiesConfiguration as well as XMLActionConfiguration, so both are supported. It's quite ugly, actually.
What I'm saying is that the configuration internals should be reworked to allow for generic usage. views.properties (or actions.xml, I don't care) should be the default configuration method and support simplicity. The idea is saying, let's not depend on wacky attributes of HTTP, but instead be explicitly about action configuration. Let's admit that results can be mapped to anything (another action in the chain, a JSP, a brown widget, or a green widget). Let's admit that CommandAware depends on a parameter "command" being set. Let's admit that the "command pattern" is specific to ActionSupport, and yet we're making commands core to the configuration to help with simplicity (Foo.action=Foo!bar). Let's admit that passing parameters to an action via GET requests is sloppy and that internally, we need to do more to support generic frameworks. Then, after we admit all that, let's admit that simplicity and power can be combined in a single deliverable. Let's admit that it IS possible to upgrade configuration power while still being able to let users upgrade to this new version and not have to change a thing, since backwards compatibility and simplicity will be the first priority. If you require more complete examples from me, I'll be more than happy to write some up. I'd also appreciate it if everyone concerned with this actually read the source (I'm familiar with 100% of the WebWork source, mind you). Look at the webwork.config package. Look at various ActionFactoryProxies that use the configuration. Then tell me there isn't room for improvement while still maintaining complete and utter simplicity. -Pat ----- Original Message ----- From: "Bill Lynch" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 04, 2002 12:20 PM Subject: Re: Configuration (was RE: [OS-webwork] Webwork Security Requirements) > I agree with you and Maurice - keeping everything as simple as possible is huge. > However, I think supporting 2 configuration options (XML vs properties) is > actually not simple and I think we should drop the properties file for 2.0. I > fail to see how the XML file is any more complex than the properties file - in > fact, I think it's more clear because you at least know what the parts of > "Foo.success=Bar.action" on face (thanks to how declarative XML is). A view is a > <view> and an alias is an attribute of <action>. > > Also, which configuration option should a newbie use? There's no dox to this to > my knowledge. If there's only one choice then it's pretty clear which one to use. ;) > > Basically, let's have a rock-solid simple XML config, with the option to > override the config loading so people can use their own props config or > something else if desired. > > Best Regards, > --Bill > > Hani Suleiman wrote: > > Again, as if this hasn't been reiterated enough times. simplicity is > > key. People like views.properties, why not keep them happy? It's like > > the propertytag debate. People like the idiosyncratic way it worked, why > > modify it just to enforce some arbitrary perception of correctness? > > > > I really do like Maurice's approach of keeping things as simple as > > possible. I likewise feel that everyone should develop an instant > > knee-jerk reaction AGAINST adding more configuration options for users > > to be befuddled by, and that it should be viewed as a distasteful last > > resort. > > > > On Monday, November 4, 2002, at 02:46 PM, Joseph Ottinger wrote: > > > >> Sure, but is it all about what you can do and not about how? I certainly > >> see your point, but that calls into question why there are two mechanisms > >> at all, much less how the mechanisms are invoked. Why not have one > >> mechanism that does it all? (I know that while my vote doesn't count for > >> much in WW, I'd rebel against losing views.properties. It's my friend. It > >> keeps me warm at night. It fights off the trolls.) > >> > >> --------------------------------------------------------- > >> Joseph B. Ottinger [EMAIL PROTECTED] > >> http://enigmastation.com IT Consultant > >> > >> On Mon, 4 Nov 2002, Maurice Parker wrote: > >> > >>> > >>> Joseph Ottinger wrote: > >>> > >>>> No, actually I see his point: We add a configuration option that tells > >>>> webwork how to configure views. That enables people like me, who are > >>>> addicted to the raw simplicity of views.properties, to be happy... > >>>> while > >>>> it allows him to have his custom frobnigator that nobody ELSE will ever > >>>> use or care about just as well. I think that's probably a justifiable > >>>> change. > >>>> > >>> Go reread my reply to Pat. His custom frobnigator doesn't do anything > >>> that I couldn't do with even views.properties. > >>> > >>> Check out this example from view.properties: > >>> > >>> jasperTest.action=jasperreports.OrderList > >>> jasperTest.success=orderList.jasper?dataSource=orders > >>> > >>> Last I checked you could also do this with Actions. Maybe a param tag > >>> in actions.xml would make this more elegant, but that's about it. > >>> > >>> -Maurice > >>> > >>>> > >>>> --------------------------------------------------------- > >>>> Joseph B. Ottinger [EMAIL PROTECTED] > >>>> http://enigmastation.com IT Consultant > >>>> > >>>> On Mon, 4 Nov 2002, Maurice Parker wrote: > >>>> > >>>> > >>>> > >>>>> Joseph Ottinger wrote: > >>>>> > >>>>> > >>>>> > >>>>>> +1! Pat is a god! (He told me to say that so I'm blindly > >>>>>> worshipping him.) > >>>>>> > >>>>>> Actually... I still vote +1, and Pat's just another frood in > >>>>>> PsychoDelusionLand. > >>>>>> > >>>>>> > >>>>>> > >>>>> Well I say he's on something that's harming his short term memory. I > >>>>> rail on how complicated the webwork.properties file is and he proposes > >>>>> yet another configuration option. > >>>>> > >>>>> Pat, put down the pipe! :-) > >>>>> > >>>>> -Maurice > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> ------------------------------------------------------- > >>>>> 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 > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> ------------------------------------------------------- > >>> 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 > >> > > > > > > > > ------------------------------------------------------- > > 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 ------------------------------------------------------- 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
