[OS-webwork] Re: Problem with the xxx[] expression
At 15.07 04/11/2002, [EMAIL PROTECTED] wrote: I'm pretty sure this is a bug. I've filed it in Jira and assigned it to myself. http://jira.opensymphony.com/secure/ViewIssue.jspa?id=21461 I seem to recall someone posting a JSP that recreated the problem, but I can't find it. If someone would post a copy of it to the Jira issue, I would really appreciate it. Thanks for looking into it. I've posted to the issue the JSP page I mentioned earlier on this mailing list. Sebastiano Pilla E-TREE S.p.a. Via Fonderia 43 - 31100 Treviso (Italy) phone +39.0422.3107 fax +39.0422.310888 http://www.e-tree.com http://www.webanana.com --- 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
RE: [OS-webwork] Webwork Security Requirements
Or we could have the webwork.action.packages property set the root packages to search from, so that if you have an action foo.bar.Foo1, and webwork.action.packages=foo, then a url like http://example.com/bar/Foo1.action would look for bar.Foo1, then foo.bar.Foo1. In other words, use the part of the package after the set prefixes as the path to the action in the url. Alias's could be created either in the same package (alias=foo1) or in a different package (alias=/bar2/foo1). Then the JSP's could be found the same way they are now, based on the path (in this case looking in /bar for JSP views). This would allow you to know what paths your actions are going to be executed under, so you can secure them. Jason -Original Message- From: Maurice C. Parker [mailto:maurice;vineyardenterprise.com] Sent: Saturday, November 02, 2002 7:29 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Webwork Security Requirements This is Jira issue WW-53 (http://jira.opensymphony.com/secure/ViewIssue.jspa?key=WW-53). I have stored the meatiest portions of this thread there so that we can remember this stuff for a future release. Here's my comment that I attached in Jira: Mike's last suggestion is much more palatable. Perhaps it could even be boiled down further. If we add concept of relative vs. absolute addressing to aliases then you wouldn't even need the new attribute. This would be using the action in the current directory: action name=Foo1 alias=foo1 view name=successfoo.jsp/view view name=inputfooform.jsp/view /action This would only allow you to access the action in it's absolute address: action name=Foo1 alias=/secure/blah/foo1 view name=successfoo.jsp/view view name=inputfooform.jsp/view /action That still leaves the issue of using actual class names as actions. Perhaps in a distant future release require that the alias be used and not allow the direct utilization of classnames. -Maurice On Friday, November 1, 2002, at 08:54 PM, Mike Cannon-Brookes wrote: Actually - I'm not sure I agree. Personally, I see the 'non path mapped' nature of WebWork actions as a flaw. I haven't found one good use for them yet. I would love to see something to stop actions from moving. I think the configuration can be made very simple - it need not be as complex as Jason listed here. action name=Foo1 alias=foo1 path=/secure/blah view name=successfoo.jsp/view view name=inputfooform.jsp/view /action Just an optional path element is all that's really needed - there could also be a 'default path' attribute at the top of the file actions - that's not really a lot of complexity for such a needed feature is it? -mike On 2/11/02 12:28 PM, Maurice C. Parker ([EMAIL PROTECTED]) penned the words: Guys, Adding more junk to the Actions.xml is a sure way fire way to make using WebWork more difficult. Do a comparison of our mapping file and Struts and you will see what I'm talking about. Jason, we've been over this repeatedly. People on the list have given you many helpful suggestions to solve your problem ranging from writing a security filter to clever web.xml configurations. You have been given a solution, it's now up to you to implement it. -Maurice On Friday, November 1, 2002, at 06:40 PM, Patrick Lightbody wrote: Jason, I agree. I believe that configuration in WebWork is one area of improvement that should be addressed in the next version. I'll jot up some ideas I've had as well as yours. Maybe if we get a Wiki set up soon we can drop stuff there. -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: Opensymphony-Webwork@Lists. Sourceforge. Net [EMAIL PROTECTED] Sent: Friday, November 01, 2002 1:06 PM Subject: [OS-webwork] Webwork Security Requirements I'm hoping that at the beginning of next year we'll be able to replace the web framework we're using (a proprietary one built by the consultants we brought in to get us kick-started) with Webwork. One of the drop dead requirements is going to be easy integration with J2EE declarative security. We need to be able to secure paths using deployment descriptors. Right now this is impossible in webwork because of the way paths are used: not as paths for finding actions, but as paths for finding JSPs. You can run an action from any path, if you know its name. I'm not sure of the best way to handle this in Webwork, but I would think this is a common requirement for J2EE apps, and most users won't want to have to write a security framework like Atlassian did for Jira. One possible solution would be to be able to break the config files up into multiple configuration files (good for multi-developer concurrent development anyway) and be able to assign each of these config files a path that they configure the app for. So you have Actions.xml: actions actionset name=foo path=/foo configfile=foo.xml/ actionset
[OS-webwork] Re: Webwork Security Requirements
Why can't you write a filter that reads a config file and checks the incoming URL to see if it is requesting an action that you would like to restrict access to? How does that solution not solve your problem? I originally opened WW-53 because WebWork does not let you secure your application in the standard way via web.xml. Adding a security filter does not solve this problem. The fundamental problem is that WebWork ignores the path, hence trying to protect a path via web.xml is made unnecessarily painful. One could argue that because of this WebWork is not even J2EE compliant. I have no idea why the decision was made for WebWork ignore the path (does anyone remember the reasoning?). IMHO it was a bad decision, however I guess it stays for backwards compatibility, but there needs to be a way to override this. Not everyone wants to write a filter. Not everyone even has that option - for example how would security implemented via filters propogate down to the EJB layer without resorting to using appserver specific calls? Anyway, I'm glad to see that WW-53 has been reopened and it looks like something will be done to address the issue. You're absolutely right in saying that WW doesn't need a secuirty framework - being able to lock the path should be all that is needed. Chris --- 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
[OS-webwork] Re: Re: Webwork Security Requirements
Ahh I see, thanks for the heads up on that one (another good tip to add to the documentation if it's not there already?). It would be especially nice if whatever solution is chosen to the path problem could take this into account, ie so you can use web.xml AND skins. Perhaps by specifying which are allowable paths, and ignoring any others? Cake and eat it too and all that... :) Just a thought anyway. It's so you can skin your views. It does get used, and you will be very grateful for it if you ever have to change the look-n-feel of your site or run multiple look-n-feels (i.e. branding for multiple customers). -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
RE: [OS-webwork] Webwork Security Requirements
Let's not play at semantics here with pedantic trivialities. Replace can't support J2EE declarative security with only supports J2EE declarative security in a way which is so cumbersome as to be unusable in a non-trivial system and re-read it. The point isn't that it's impossible to use web.xml, but that it's made unusable in any practical sense because of the way the current setup works. You'd have to either: A) come up with a naming convention such as *Buyer.action to secure for buyers B) Have a separate web.xml entry for each action and each alias Of these, A) is probably the most usable option, but hardly meets the goals of separating deployment concerns for security and development concerns. B) is just ridiculous if you get over 10 actions or so, as you'll probably have at least as many aliases. This is simply NOT manageable. In our current app, we have over 400 handlers (the equivalent of an action in the framework we currently have to use). So, for the classes plus aliases, we're talking over 800 entries we'd have to have in web.xml. Is the declare each action in your web.xml separately option really the best practice you want to put out there for Webwork for securing apps using J2EE declarative security? Jason -Original Message- From: Maurice Parker [mailto:maurice.parker;pmic.com] Sent: Monday, November 04, 2002 11:22 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Webwork Security Requirements Jason Carreira wrote: - (on viruswall) email-body was scanned and no virus found - --- - I guess that's possible, but it's not really the point. J2EE provides declarative security that works well enough, and that's what we're using. I can tell you now that if Webwork can't support J2EE declarative security, I won't be able to get it in here, and I'm sure there are a lot of other shops where that will also be the case. As a framework which supports servlet development, Webwork should support the J2EE security framework, even if it allows people to bypass it and do their own security implementations. J2EE decaritive security for a web application is taken configured via your web.xml file. To say that WebWork doesn't support this is patently false. It is very possible to use you web.xml file to restrict access to your Actions. It's your opinion that it's too inconvient to declare each action in your web.xml separately and you want to do it based on directory wildcards. We will probably add the ability only reference alias' by thier absolute pathname in a future version, but I think it highly unlikely that you will configure permissions in you actions.xml. In the meantime either configure you Actions individually in you web.xml file or write you own filter to do directory based restriction. -Maurice Security products have a vested interest in plugging into app server security frameworks, but probably won't support a webwork security framework without having to go in and code the interconnects ourselves. Jason -Original Message- From: Maurice Parker [mailto:maurice.parker;pmic.com] Sorry if I was overly harsh, but the fact that WebWork will not integrate a security framework has been discussed and decided upon more than once. Why can't you write a filter that reads a config file and checks the incoming URL to see if it is requesting an action that you would like to restrict access to? How does that solution not solve your problem? -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
Re: [OS-webwork] Webwork Security Requirements
snip Why not just provide two ServletDispatchers? One that works the way everything does now (but just reading views.properties) and another that reads a mapping file that maps path to WebWork alias/action: mapping.properties: /secure/Foo.action=Foo views.properties Foo.action=Foo This could be done right now by just writing your own MappedServletDispatcher, maybe someone should write it and then contribute it back to OpenSymphony. This is a perfect example where we can add more features without complicating the basic principle of keeping up-front usage simple. That's my two cents, but of course, I'll go with whatever the core WebWork decide. -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
[OS-webwork] Website and Wiki [Was: What a WebWork developer thinks]
snip Yup, as documentation grows and gets better, we should also think about having an OpenSymphony Wiki that create a living community as well. Also, as Joe mentioned, why not take our own medicine and make the OS website use WebWork and be more interactive? So.. this is a call for anyone out there that has a few hours to spare on helping the OpenSymphony website out... anyone? -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
Re: [OS-webwork] Website and Wiki [Was: What a WebWork developerthinks]
Jive is a WebWork application now. Maybe we qualify for a non-commercial license... Joseph Ottinger wrote: Actually, if we're REALLY going to take our own medicine, we should use WebCompass and use THAT to do the wiki-type functionality. - Joseph B. Ottinger [EMAIL PROTECTED] http://enigmastation.comIT Consultant On Mon, 4 Nov 2002, Patrick Lightbody wrote: snip Yup, as documentation grows and gets better, we should also think about having an OpenSymphony Wiki that create a living community as well. Also, as Joe mentioned, why not take our own medicine and make the OS website use WebWork and be more interactive? So.. this is a call for anyone out there that has a few hours to spare on helping the OpenSymphony website out... anyone? -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 --- 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
Re: Configuration (was RE: [OS-webwork] Webwork Security Requirements)
In general idea, I'm all for it. However, I think actions.xml has many problems itself. For example, the fact that commands are built in to the configuration DTD even though commands are an optional piece included in ActionSupport. See my blog entry a while back for an example configuration (a bit verbose, but the idea is there). Maybe we could take something like that and trim it down? http://radio.weblogs.com/0108886/2002/09/15.html -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 04, 2002 9:30 AM Subject: Configuration (was RE: [OS-webwork] Webwork Security Requirements) What are the current thoughts on moving to one form of configuration (i.e. getting rid of views.properties and just using actions.xml)? -Original Message- From: Patrick Lightbody [mailto:plightbo;cisco.com] Sent: Monday, November 04, 2002 12:24 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Webwork Security Requirements Oh, good! I just thought two different ServletDispatchers would be nice to offer flexibility, but maybe only one is needed. Either way, doing it this way is nice also because internal actions are now not exposed at all. One of these days we might want to rename views.properties, since it's not views at all anyone, but action definitions. In fact, I'd be all for requiring an action to be aliased before it can be used (not more looking in the package). I alias all my actions before using them. This sorta goes back to my original hope that configuration be simplified and make much more sense in version 2.0. -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
Re: Configuration (was RE: [OS-webwork] Webwork Security Requirements)
+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. - Joseph B. Ottinger [EMAIL PROTECTED] http://enigmastation.comIT Consultant On Mon, 4 Nov 2002, Patrick Lightbody wrote: 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. I was thinking about this some more and actually, maybe consolidating views.properties and actions.xml is actually the _wrong_ way to go. Instead, why not do something similar to what happens today, except make a few changes: - keep global configuration (a la webwork.properties) seperate from action configuration (a la views.properties) - 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?) - 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. 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. -Pat - Original Message - From: Maurice Parker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 04, 2002 10:41 AM Subject: Re: Configuration (was RE: [OS-webwork] Webwork Security Requirements) Patrick Lightbody wrote: As for parsing whether the result is an action or a view, it's not that it's non-trivial, it's that it's impossible, since the user might want either behavior! It better not be impossible. All that GenericDispatcher code you added tries to do that today, and requires the ability to do so to function correctly. If it's impossible, I can't see how we can include it in the upcoming 1.3 release and have zero defects. -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
Re: [OS-webwork] Re: Configuration
Patrick Lightbody wrote: You're right, I'm not giving concrete examples. They are there, trust me, I just haven't written them down. I'd like for this issue to be kept open until I get a chance to give you some real examples. In fact, I'll even write some code in the sandbox/xwork module that is a working example. Or you could fix those bugs introduced with the GenericDispatcher. -Maurice Until I get some examples and code in place, I'll not bring this up again. -Pat - Original Message - From: Maurice Parker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 04, 2002 12:45 PM Subject: Re: [OS-webwork] Re: Configuration Patrick Lightbody wrote: 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. Actions by definition should not know about their environment. Foo.success=Bar.action means to chain to the next action. Period. The mechanism whether it be by doing HTTP forwards or by going through an internal loop is an implementation detail that should be hidden from the end user. 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. The point behind giving this example was to show you that you haven't any new funtionality. As to using HTTP specific features, all actions have parameters if in a Servlet container or not. If you specify them via an HTTP query string or with a special XML tag is irrelevant. They're still parameters. If we need syntactic sugar, we can add a param XML tag to actions.xml. And just to be perfectly clear, this change would have _zero_ effect on anyone. I fail to see how it would benifit anyone either. Show me how to do something with your new configuration scheme that I can't already do today. -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
Re: Configuration (was RE: [OS-webwork] Webwork Security Requirements)
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? s/people/webwork developers I have had plenty of discussions with lots of people in #java about the property tag and it's pretty much universal that the current behaviour is wierd at best. (Like the ww:propertyfoo:bar//ww:property instance: does that print or just push? That depends on the output of foo:bar/!). And again, I am not for changing anything, I want to add a logical and simple system, one that will fix the dreaded issue in jira about wanting ww:property value=foo/ to push, because doing that isn't possible at all with the current tags but would be trivial with two tags ww:value and ww:render (or push/print, or use/out or whatever name you prefer). 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. Remind me again who is suggesting we replace views.properties with the xml file. // Anders Hovmöller --- 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
[OS-webwork] how are you implementing security right now?
as it stands, what is the method you guys are using for security right now? someone suggested filters, what other options are there? --- 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
Re: Configuration (was RE: [OS-webwork] Webwork SecurityRequirements)
Anders, Re: property tag - we have decided (ad infinitum) that it is simple, it just needs better documentation. We do not want value, render, print or push tags - they are MORE confusing. Keeping the taglib small and simple IS a good goal. Re: views.properties - personally I vote +1 to deprecating it and always using actions.xml - see next mail. -mike On 5/11/02 8:03 AM, boxed ([EMAIL PROTECTED]) penned the words: 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? s/people/webwork developers I have had plenty of discussions with lots of people in #java about the property tag and it's pretty much universal that the current behaviour is wierd at best. (Like the ww:propertyfoo:bar//ww:property instance: does that print or just push? That depends on the output of foo:bar/!). And again, I am not for changing anything, I want to add a logical and simple system, one that will fix the dreaded issue in jira about wanting ww:property value=foo/ to push, because doing that isn't possible at all with the current tags but would be trivial with two tags ww:value and ww:render (or push/print, or use/out or whatever name you prefer). 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. Remind me again who is suggesting we replace views.properties with the xml file. // Anders Hovmöller --- 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
Re: [OS-webwork] Re: Configuration
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
RE: [OS-webwork] Views.properties - to deprecate or not
I created a JIRA issue for multiple config files at http://jira.opensymphony.com/secure/ViewIssue.jspa?key=WW-82 +1 for deprecating views.properties. Multiple configuration methods make webwork more confusing, not less -Original Message- From: James Cook [mailto:jim.cook;dot.state.oh.us] Sent: Monday, November 04, 2002 5:22 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Views.properties - to deprecate or not I don't particularly like actions.xml, and I really like the simplicity of views.properties. I find it much easier to read. I'm ambivalent about deprecating views.properties only because it is a bitch to maintain in a multi-user environment. At early stages in a project, it is a heavily edited file that CVS doesn't always play well with. The upside of actions.xml is the ability to separate the file out into multiple XML documents and aggregate them in actions.cml using the XML entity format. +0 -Original Message- From: [EMAIL PROTECTED] [mailto:opensymphony-webwork-admin;lists.sourceforge.net]On Behalf Of Mike Cannon-Brookes Sent: Monday, November 04, 2002 5:00 PM To: [EMAIL PROTECTED] Subject: [OS-webwork] Views.properties - to deprecate or not Hey all, OK - let me see if I can boil this issue down to simplicity. Should we deprecate views.properties? In my view, it should be deprecated - ie it will still work, but will no longer be documented or referred to. - actions.xml is a far simpler format to read - anyone using J2EE MUST understand XML configuration files by now already - maintaining two 'default' view configuration mechanisms can only confuse new users. +1 from me. -mike --- 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
RE: [OS-webwork] Views.properties - to deprecate or not
Votes for deprecation: - Justen Stepka - Jason Carreira - Joseph Ottinger - Hani Suleiman - Mike Cannon-Brookes - Aapo Laakkonen Votes for keeping views.properties: - James Cook For Mike: Is it possible to have these feature polls in JIRA? If not, then would you go ahead and implement it, :-)? --- 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
Re: [OS-webwork] More thoughts on Configuration
Isn't this is a violation of basic programming principals - don't put lots of data into a string? :) Could we just make a 'ViewObject' that is returned instead? (ie for backward compatibility - ViewObject.getString() returns the current think - so no change?) That is confusing (rereading) - basically, we should pass around objects not strings when representing more than one idea? Cheers, Mike On 5/11/02 11:45 AM, Patrick Lightbody ([EMAIL PROTECTED]) penned the words: A while back when Rickard asked what else, besides GenericDispatcher, was needed to make WebWork a more generic command framework, I responded with the following list: -Ditch JavaBeans, replace with OGNL -Provide more dispatchers based on GenericDispatcher (SOAP, Servlet, Swing, etc) -make configuration more powerful (but still simple as always) -provide libraries/tags for all supported views -documentation overhaul, inlcuding a best practices guide -lots of examples that aren't web-based (SOAP and Swing, especially) -an implementation for the Wafer project (http://www.waferproject.org) -support a flexible input validation/type conversion system for all dispatchers I believe I've nailed down, in words, why the current configuration is sub-optimal. The Configuration object uses a single method: String get(String) This means that even though something like actions.xml is in a nice structure, it eventually gets pushed back down to the structure that views.properties uses. For example, take a look at this from ConfigurationViewMapping: returnValue = Configuration.get(actionName+!+command+.+aViewName); ... returnValue = Configuration.get(actionName+.+aViewName); As you can see, not only is the view mapping but also the CommandAware stuff (something inherently built in to ActionSupport only, meaning it shouldn't be in core configuration stuff). This is a very flat structure. It also doesn't leave room for allowing us to specify parameters for our actions. An example of this is: Say I have a SendEmail action. I want to be able to use the aciton in various places. It sends generic emails out, so I want to re-use it. A parameters to be passed in would be the subject, as well as the message body. I'd be very nice to be able able to alias SendConfirmationEmail and also SendPasswordEmail: SendConfirmationEmail would be mapped to SendEmail but would have two paramters auto set (as in my code doesn't need to do this): subject and message. Same goes for SendPasswordEmail. By using an ActionConfig (see sandbox/xwork/config) you can achieve this. -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
