RE: [OS-webwork] Ognl status
We should also check out http://jbeans.org/ for this stuff... It looks pretty cool. -Original Message- From: Patrick Lightbody [mailto:plightbo;cisco.com] Sent: Thursday, October 31, 2002 1:53 PM To: [EMAIL PROTECTED] Cc: Drew Davidson Subject: Re: [OS-webwork] Ognl status Followup: Drew Davidson pointed out that precompiling the parse trees would speed things up a TON, which it did: Total time (OGNL): 2213 Total time (OGNL compiled): 100 Total time (WebWork BeanUtil): 80 Total time (Commons-BeanUtils): 111 You can run these tests yourself by checking out sandbox and running ant from within the xwork directory. Ognl will allow us to write TypeConverters for each bean and/or property, but it doesn't have a way to convert data back to a desired form (String in our case, but since this is XWork, we'll want to support any type of conversion). -Pat - Original Message - From: Patrick Lightbody [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 30, 2002 4:44 PM Subject: [OS-webwork] Ognl status OK, I was playing with Ognl today and performance became a problem. Below is my post to ognl-interest, I'll keep everyone posted. In the meantime, maybe ditching PropertyEditors but coming up with our own (FAST) BeanUtil implementation that doesn't use PropertyEditors would be best. It shouldn't need to be very complex. The main things we need are: - complete data conversion for both setting and getting data - ability to write our own data converters for each webwork action (not class) - Uh oh... I may have hit a major roadblock in trying to switch to using Ognl in WebWork: it appears to be VERY slow. I ran a simple test, setting 7 different attribute types (some of which involve type conversion), repeating 1000 times: Total time (OGNL): 2463ms Total time (BeanUtil): 91ms BeanUtil is a WebWork utility method that uses the JavaBeans APIs (PropertyEditor, etc). Any thoughts on this? I'm using the optimized binary under JDK 1.4.1. --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] WebWork 1.3
All, I think we need to put together a 1.3 release sometime within the next month or so. The focus of the next release needs to be quality above all else. The 1.2.x releases were very poor and there are people needing bugfixes for problems introduced with them. To move us toward a higher quality release I have begun to add tests to CVS. In the future it should be a requirement that all the tests run before committing new code to CVS. Currently CVS is so bug riddled that if we followed that rule no tests would make it into the repository. All tests will run successfully before the next release. The acceptance tests use HttpUnit. Feel free to use just Junit or Mock objects for unit tests, but always have an HttpUnit test for acceptance. The reason that I am avoiding using Mock objects for acceptance is because I want us to have a full test suite that can be used to assure compatibility across containers. My goal is to be able to announce on the list that a release is coming and to have every one run the test suite to make sure WW is bug free on their favorite container. I'm also going to be going through Jira over the next few weeks and responding to all the outstanding issues. Bugs will be replicated in the test suite and then fixed before the next release. If you posted a problem to the list and you're not sure if anyone notice, make sure you file it at http://jira.opensymphony.com . While we are trying to get CVS stabilized, I would like to ask everyone to refrain from adding new features to the source tree. Once we have a solid release out, then I think we should untable discussions about what would be the next big move for WebWork. -Maurice --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork 1.3
Way to go Maurice! - Original Message - From: Maurice C. Parker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 01, 2002 6:06 AM Subject: [OS-webwork] WebWork 1.3 All, I think we need to put together a 1.3 release sometime within the next month or so. The focus of the next release needs to be quality above all else. The 1.2.x releases were very poor and there are people needing bugfixes for problems introduced with them. To move us toward a higher quality release I have begun to add tests to CVS. In the future it should be a requirement that all the tests run before committing new code to CVS. Currently CVS is so bug riddled that if we followed that rule no tests would make it into the repository. All tests will run successfully before the next release. The acceptance tests use HttpUnit. Feel free to use just Junit or Mock objects for unit tests, but always have an HttpUnit test for acceptance. The reason that I am avoiding using Mock objects for acceptance is because I want us to have a full test suite that can be used to assure compatibility across containers. My goal is to be able to announce on the list that a release is coming and to have every one run the test suite to make sure WW is bug free on their favorite container. I'm also going to be going through Jira over the next few weeks and responding to all the outstanding issues. Bugs will be replicated in the test suite and then fixed before the next release. If you posted a problem to the list and you're not sure if anyone notice, make sure you file it at http://jira.opensymphony.com . While we are trying to get CVS stabilized, I would like to ask everyone to refrain from adding new features to the source tree. Once we have a solid release out, then I think we should untable discussions about what would be the next big move for WebWork. -Maurice --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Ognl status
I'll get some demo implementations of JBeans in the sandbox/xwork module and post my results. -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 01, 2002 4:59 AM Subject: RE: [OS-webwork] Ognl status We should also check out http://jbeans.org/ for this stuff... It looks pretty cool. -Original Message- From: Patrick Lightbody [mailto:plightbo;cisco.com] Sent: Thursday, October 31, 2002 1:53 PM To: [EMAIL PROTECTED] Cc: Drew Davidson Subject: Re: [OS-webwork] Ognl status Followup: Drew Davidson pointed out that precompiling the parse trees would speed things up a TON, which it did: Total time (OGNL): 2213 Total time (OGNL compiled): 100 Total time (WebWork BeanUtil): 80 Total time (Commons-BeanUtils): 111 You can run these tests yourself by checking out sandbox and running ant from within the xwork directory. Ognl will allow us to write TypeConverters for each bean and/or property, but it doesn't have a way to convert data back to a desired form (String in our case, but since this is XWork, we'll want to support any type of conversion). -Pat - Original Message - From: Patrick Lightbody [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 30, 2002 4:44 PM Subject: [OS-webwork] Ognl status OK, I was playing with Ognl today and performance became a problem. Below is my post to ognl-interest, I'll keep everyone posted. In the meantime, maybe ditching PropertyEditors but coming up with our own (FAST) BeanUtil implementation that doesn't use PropertyEditors would be best. It shouldn't need to be very complex. The main things we need are: - complete data conversion for both setting and getting data - ability to write our own data converters for each webwork action (not class) - Uh oh... I may have hit a major roadblock in trying to switch to using Ognl in WebWork: it appears to be VERY slow. I ran a simple test, setting 7 different attribute types (some of which involve type conversion), repeating 1000 times: Total time (OGNL): 2463ms Total time (BeanUtil): 91ms BeanUtil is a WebWork utility method that uses the JavaBeans APIs (PropertyEditor, etc). Any thoughts on this? I'm using the optimized binary under JDK 1.4.1. --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Plea from a dummy
You wrote: For the dummies: ww:property has TWO uses: 1: ww:property value=3Dx / will grab the value of x and print it 2: ww:property value=3Dx ... /ww:property will grab the value of = x and make it 'available' between the tags. That's it! Some more examples of fun to be had (from my 'teach ww to the coworkers= ' spiel) ww:property value=3Dx/y will print getX().getY() ww:property / will print what's on the top of the stack (very useful = to debug where you are! Why is #2 above useful? It makes your code simpler and easier to read! ww:property value=3DsomeUser ww:property value=3Dname / ww:property value=3DfullName / ww:property value=3Demail / /ww:property As a dummy, I really appreciate this description of what the property tag does. It's clear, concise, complete, and useful. The only problem is its location: not in the documentation where all us dummies can easily find it, but on the mailing list where most of the participants already know how it all works. Let me remind you what the official documentation says about the property tag: property tag Used to retrieve a value and print it out. By default, it will escape HTML characters for tags with *no* bodies. Tags with bodies will not be escaped. You can override this with explicit setting of the escape attribute. Quoted text that is escaped will have its outer quotes stripped. Attributes attribute requied id F value F escape F In this example, property will call getTime() on the object pointed to by @timer. Time:webwork:property value=@timer/time/ms You guys have a great product in WebWork, but it is *incredibly* frustrating trying to find answers about how to use it in the skimpy documentation. For all the ink you spill over issues like this and null tests vs. boolean tests, you would think some of it could find it's way into the docs where everybody would be enlightened. Just a plea from a humble dummy. I know I'm not the only one. Geoff --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Plea from a dummy
Geoff, I hear ya, and I feel your pain. The problem is that nobody (me especially) likes to write documentation. Open Source projects are based on volunteer labor and it's not like you can make people do what you want them to do. If Matt hadn't gritted his teeth and bore down on the problem you wouldn't have the skimpy documentation that exists today. Your feedback was good. We need to know that the docs still need more work. But... Geoff Carruthers wrote: You guys have a great product in WebWork, but it is *incredibly* frustrating trying to find answers about how to use it in the skimpy documentation. For all the ink you spill over issues like this and null tests vs. boolean tests, you would think some of it could find it's way into the docs where everybody would be enlightened. For all the ink you spilled in complaining about the state of the documentation, you could have edited the pertinent parts of what you had read on the list into the current docs and posted them in Jira. Then I could merge them without spending all day checking my bad spellling and grammers and we could really help somebody. -Maurice --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Validation in xwork (Ognl?)
I am not asking for more help with validation really. But if BeanUtil cannot set a property because the conversion to the type cannot be made, then it catches the IllegalArgumentException thrown by the PropertyEditor and calls the Action if it implements IllegalArgumentAware. With OGNL there must be some way of handling errors as well I guess? And this is the kind of validation I am talking about, it's a kind of pre-validation before any doValidation method is called etc. But from your description it seems as if it could be handled then, if you can just make the hook to the IllegalArgumentAware interface somehow? Best regards, Dick Zetterberg [EMAIL PROTECTED] - Original Message - From: Patrick Lightbody [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 01, 2002 5:14 PM Subject: Re: [OS-webwork] Validation in xwork (Ognl?) Ognl won't help with validation (maybe we can look at FormProc for something like that), but it will do all levels of type conversion you require. That includes global level, as well as bean level, and even property level. -Pat - Original Message - From: Dick Zetterberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 01, 2002 3:14 AM Subject: Re: [OS-webwork] Validation in xwork (Ognl?) Hi there, When implementing the new BeanUtil replacement it would be good if it could allow you to also specify parse formats on a global (static) level as well. This is possible with the current implementation by registering my own PropertyEditors with the PropertyEditorManager class. I use this today in order to override several of Webworks property editors for example DateEditor and different number editors. It is good because I can then: - Use one standard dateeditor throughout my application. That editor supports the different date formats that my customer wants to allow. The dateformat does not necessary have to follow a standard but can be any format the customer prefers. - Have localised/customised error messages generated from my property editors, for example when input in a date or number field is not valid (not parseable). - I do not have to clutter my code by creating alot of BeanInfo classes, unless I really need it. So it would be nice if the new implementation would allow something similar as well. Best regards, Dick Zetterberg [EMAIL PROTECTED] - Original Message - From: Patrick Lightbody [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 31, 2002 1:44 AM Subject: [OS-webwork] Ognl status In the meantime, maybe ditching PropertyEditors but coming up with our own (FAST) BeanUtil implementation that doesn't use PropertyEditors would be best. It shouldn't need to be very complex. The main things we need are: - complete data conversion for both setting and getting data - ability to write our own data converters for each webwork action (not class) --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Plea from a dummy
For all the ink you spilled in complaining about the state of the documentation, you could have edited the pertinent parts of what you had read on the list into the current docs and posted them in Jira. Then I could merge them without spending all day checking my bad spellling and grammers and we could really help somebody. I believe this falls in the give a man a fish category. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Validation in xwork (Ognl?)
When we talk about BeanUtil, that's a webwork class, right? I'm wondering because someone (James Strachan maybe?) on their blog suggested using commons beanutil... Just another thought. -Original Message- From: Patrick Lightbody [mailto:plightbo;cisco.com] Sent: Friday, November 01, 2002 3:29 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Validation in xwork (Ognl?) Yup, so we can either report the error or silently ignore it -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 01, 2002 10:59 AM Subject: RE: [OS-webwork] Validation in xwork (Ognl?) What if it fails to convert the value? Will that throw an exception? -Original Message- From: Patrick Lightbody [mailto:plightbo;cisco.com] Sent: Friday, November 01, 2002 11:15 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Validation in xwork (Ognl?) Ognl won't help with validation (maybe we can look at FormProc for something like that), but it will do all levels of type conversion you require. That includes global level, as well as bean level, and even property level. -Pat - Original Message - From: Dick Zetterberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 01, 2002 3:14 AM Subject: Re: [OS-webwork] Validation in xwork (Ognl?) Hi there, When implementing the new BeanUtil replacement it would be good if it could allow you to also specify parse formats on a global (static) level as well. This is possible with the current implementation by registering my own PropertyEditors with the PropertyEditorManager class. I use this today in order to override several of Webworks property editors for example DateEditor and different number editors. It is good because I can then: - Use one standard dateeditor throughout my application. That editor supports the different date formats that my customer wants to allow. The dateformat does not necessary have to follow a standard but can be any format the customer prefers. - Have localised/customised error messages generated from my property editors, for example when input in a date or number field is not valid (not parseable). - I do not have to clutter my code by creating alot of BeanInfo classes, unless I really need it. So it would be nice if the new implementation would allow something similar as well. Best regards, Dick Zetterberg [EMAIL PROTECTED] - Original Message - From: Patrick Lightbody [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 31, 2002 1:44 AM Subject: [OS-webwork] Ognl status In the meantime, maybe ditching PropertyEditors but coming up with our own (FAST) BeanUtil implementation that doesn't use PropertyEditors would be best. It shouldn't need to be very complex. The main things we need are: - complete data conversion for both setting and getting data - ability to write our own data converters for each webwork action (not class) --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing
Re: [OS-webwork] WebWork CookBook
Maybe we should set up a Wiki at wiki.opensymphony.com? -Pat - Original Message - From: Mike Cannon-Brookes [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Sent: Friday, November 01, 2002 4:22 PM Subject: [OS-webwork] WebWork CookBook In light of my recent 'tips' emails, I thought I'd collate them somewhere more useful online than the crappy SF mail archives: So the WebWork Cookbook was born: http://radio.weblogs.com/0107789/stories/2002/11/02/webworkCookBook.html Basically I'll just try to dump up lots of short snippets of useful information and code as I think of them. It's not a replacement to the docs (indeed this information should be merged into the docs at some stage!) but hopefully it will provide a dumping ground for useful tips and techniques. (And it's much easier to edit a story on my blog than edit the WW docs - but that's another story :)) _Please_ feel free to contribute your own brief tips! Even a few line tip of something that you 'figured out' or thought was nifty is useful to other people! Thoughts appreciated. -mike --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Webwork Security Requirements
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 name=Default path=/ packages=webwork.test action name=FormTest alias=formtest view name=successredirect.action?url=jdom.action/view view name=inputformtest.jsp/view /action action name=jdom.JDOMTest alias=jdom view name=successjdom.jsp/view /action /actionset /actions Foo.xml: action name=Foo1 alias=foo1 view name=successfoo.jsp/view view name=inputfooform.jsp/view /action action name=Foo2 alias=foo2 view name=successfoo.jsp/view view name=inputfooform.jsp/view /action Or something. Any other thoughts on how this could be done? I think this is VERY important for (Web|X)work Jason Carreira -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork CookBook
Mike, this stuffs awesome. Excellent work. I had a conversation with a coworker today about learning to use WebWork. He is extremely excited about how quickly and easily he can develop apps using SiteMesh+WebWork. He got up to speed using both in a very short period of time. The problem is the same one that Tim Dwelle pointed out. It's hard to find information in the current documentation. The example my coworker gave was ActionContext. It's powerful, but most people probably don't know how to use it 'cause it's not mentioned in the docs (that I could find). This also a great example of how to be part of an Open Source community. Mike had an idea and did something about it. He didn't talk it to death. He didn't suggest someone else do it for him. He just got it done. -Maurice On Friday, November 1, 2002, at 06:22 PM, Mike Cannon-Brookes wrote: In light of my recent 'tips' emails, I thought I'd collate them somewhere more useful online than the crappy SF mail archives: So the WebWork Cookbook was born: http://radio.weblogs.com/0107789/stories/2002/11/02/ webworkCookBook.html Basically I'll just try to dump up lots of short snippets of useful information and code as I think of them. It's not a replacement to the docs (indeed this information should be merged into the docs at some stage!) but hopefully it will provide a dumping ground for useful tips and techniques. (And it's much easier to edit a story on my blog than edit the WW docs - but that's another story :)) _Please_ feel free to contribute your own brief tips! Even a few line tip of something that you 'figured out' or thought was nifty is useful to other people! Thoughts appreciated. -mike --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
