So Mike, You guys developed the external-ref stuff, what do you think of Cameron's changes? It sounds like he made it more flexible and powerful to me...
> -----Original Message----- > From: Mike Cannon-Brookes [mailto:[EMAIL PROTECTED] > Sent: Friday, December 12, 2003 4:51 AM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] [OS-xwork] Spring IoC integration > > > Francois, > > :) > > As for why it's required, it makes everything more flexible - > and it's not required at all. Just ignore it and it will do > you no harm. > > Pico is good (for somethings) but personally I much prefer > Spring (that's a large debate for another time - each to their own) :) > > - XWorks IoC container requires interfaces on your actions. > - Pico requires a custom constructor and your own factories. > - Spring requires external references (in one way) > > You can also use Spring exactly like Pico if you want (using > constructors), but I actually like the explicitly defined > contracts that the external references give you. > > Basically treat an external reference as a chance for some > code to resolve references on the action (IoC is just one use > for them) at a user defined time (you can't do this with Pico > - it's a constructor, it's done when the object is > constructed). With the ExternalReferenceInterceptor it's a > part of the interceptor chain, so I can govern when those > references are resolved (before Params? After Params? After > Validation?) I have control. > > Anyway - some thoughts - don't get fooled by the Pico folk, > it's not the be-all-and-end-all of IoC - it's just one solution. :) > > M > > On 12/12/03 6:15 PM, "Francois Beauregard" > ([EMAIL PROTECTED]) penned the words: > > > Why all of this external reference resolver thing gets into XWork? > > > > Couldn't you just extend DefaultActionProxyFactory, > > DefaultActionInvocation and do whatever logic to integrate with the > > IoC container and/or use an interceptor? > > > > Even XWorks own IoC container does not need this kind of > modification > > to XWork.xml, it looks like it only needs an interceptor and stores > > its configuration in an xml file. > > > > You can also have a look at PicoContainer's integration (in > > NanoContainer), it is neatly done. > > > > Cheers, > > ___________________________ > > François Beauregard, b.ing. > > Vice-président > > Recherche et développement > > Pyxis Technologies > > www.pyxis-tech.com > > > > T : (450) 681-9094, poste 102 > > F : (450) 681-5758 > > [EMAIL PROTECTED] > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > Behalf Of > > Cameron Braid > > Sent: December 12, 2003 1:32 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [OS-webwork] [OS-xwork] Spring IoC integration > > > > > > It looks like noone else is interested in discussing this. > > > > I have refactored xwork so that the external refrence resolvers are > > defined as described below > > > > <xwork> > > <package name='test' extends='webwork-default'> > > > > <external-resolvers> > > <external-resolver name="test" > > class="com.opensymphony.xwork.config.TestExternalReferenceResolver"> > > <param name='stringParam'>stringParamValue</param> > > </external-resolver> > > <external-resolver name="test2" > > > class="com.opensymphony.xwork.config.Test2ExternalReferenceResolver"/> > > </external-resolvers> > > > > <default-external-resolver-ref name='test'/> > > > > <action name="TestExternalRefResolver3" > > class="com.opensymphony.xwork.ExternalReferenceAction"> > > <external-ref required="true" > name="Boo">myBoo</external-ref> > > <interceptor-ref name="debugStack"/> > > <interceptor-ref name="defaultStack"/> > > </action> > > > > <!-- test where external-resolver-ref overrides the package's > > resolver --> > > <action name="TestExternalRefResolver5" > > class="com.opensymphony.xwork.ExternalReferenceAction"> > > <external-ref name="foo" > > external-resolver-ref='test2'>myFoo</external-ref> > > <interceptor-ref name="debugStack"/> > > <interceptor-ref name="defaultStack"/> > > </action> > > > > </package> > > </xwork> > > > > I have updated the test cases to use this new structure, and added > > tests for the new features. > > > > This has required that the ExternalReferenceResolver interface be > > changed a little bit, simplifying the implementation. > > > > Previousally ExternalReferenceResolver.resolveReferences(..) had to > > resolve all external refrences for an action, where as now it just > > resolves a single refrence at a time. > > > > public interface ExternalReferenceResolver { > > public void resolveReferences(ActionInvocation invocation, > > ExternalReference reference) throws ReferenceResolverException; } > > > > This simplifies the implemetation of the resolver because > it doesn't > > need to know about the ActionConfig at all, since ExternalReference > > contains the action property name, the external ref string and the > > required boolean. > > > > It is the responsiblity of the > ExternalReferencesInterceptor to call > > the relevant resolver for each <external-ref> tag for the action. > > > > I can add a Jira task, and attach the patch if anyone is > interested. > > > > I would prefer that this code gets added before the final release. > > > > Cameron. > > > > Cameron Braid wrote: > > > >> Ross Mason wrote: > >> > >>> > >>> > >>> Cameron Braid wrote: > >>> > >>>> Ross Mason wrote: > >>>> > >>>>> > >>>>> > >>>>> Cameron Braid wrote: > >>>>> > >>>>>> I have downloaded and integrated this code though and > the tests > >>>>>> run perfectly (after creating my my own ServletContextAware > >>>>>> interface and removing refrences to the confluence packages) > >>>>>> > >>>>>> I really like the work that you have done. Though I think some > >>>>>> more work is required to be able to integrate into > xwork/webwork > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Cool! > >>>>> > >>>>>> > >>>>>> I can't see how the servlet context is set onto the > >>>>>> SpringServletContextReferenceResolver or the > ApplicationContext > >>>>>> is set onto the SpringApplicationContextReferenceResolver > >>>>>> (depending on the one that is used) > >>>>>> > >>>>>> you construct the ExternalReferenceResolver using this > code, and > >>>>>> immediately add it to the package config. > >>>>>> > >>>>>> Class erResolverClazz = > >>>>>> ClassLoaderUtil.loadClass(externalReferenceResolver, > >>>>>> ExternalReferenceResolver.class); > >>>>>> erResolver = (ExternalReferenceResolver) > >>>>>> erResolverClazz.newInstance(); > >>>>>> > >>>>>> I guess that the ServletContextAware interface could > be added to > >>>>>> webwork, though the question remains - how is the > >>>>>> ServletContextAware.setServletContext(..) method going to get > >>>>>> called ? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> We could use a ServletContextListener to set the > contexts on our > >>>>> resolvers... Could we access the packageConfig from a listener? > >>>> > >>>> > >>>> > >>>> > >>>> Yeah I guess we could, though this starts to get ugly when each > >>>> different resolver needs its own listener that is bound to the > >>>> action config api. > >>> > >>> > >>> You only need one listener to set the Servlet context on all > >>> Resolvers that are ServletContextAware. I'll attach the one I'm > >>> using to the issue. > >> > >> > >> Sounds like we need to get the DefaultComponentManager to > bootstrap > >> the external refrence resolvers ;) > >> > >> Actually... my point here was that each type of resolver... ie the > >> spring one, the XXXFramework one and any other framework > integration > >> one will require someone to code a specific > ConfigurerListener to set > >> any external resources that the resolver requires. I think that if > >> this can be done with simple parameter based configuration then it > >> will be a lot simpler. > >> > >>>> > >>>>>> > >>>>>> I propost the following soloution : > >>>>>> > >>>>>> 1 : have different SpringXXXReferenceResolver classes in xwork > >>>>>> and webwork like this : > >>>>>> > >>>>>> xwork : > Spring/ClassPathXmlApplicationContext/ReferenceResolver > >>>>>> or a Spring/FileSystemXmlApplicationContext/ReferenceResolver > >>>>>> webwork : > Spring/WebApplicationContext/ReferenceResolver - using > >>>>>> > > > WebApplicationContextUtils.getWebApplicationContext(ServletActionConte > > xt.get > > ServletContext()) > >>>>>> to obtain the application context > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> I agree, we should have different implementations, > separated like > >>>>> this. In my test case I have provided a > >>>>> Spring/XmlFileApplicationContext, so we could just > refactor that > >>>>> out. > >>>> > >>>> > >>>> > >>>> > >>>> Certainly can. > >>>> > >>>>>> > >>>>>> This works find for webwork based apps, though for xwork based > >>>>>> apps that the > >>>>>> SpringClassPathXmlApplicationContextReferenceResolver and > >>>>>> SpringFileSystemXmlApplicationContextReferenceResolver require > >>>>>> configuration to specify the filename.. therfore step two is > >>>>>> required : > >>>>>> > >>>>>> 2 : allow for external refrence resolvers to be > declards by name, > >>>>>> class and to be parameterizable like interceptors. > the refer to > >>>>>> the by name instead of className > >>>>>> > >>>>>> e.g. : > >>>>>> > >>>>>> <xwork> > >>>>>> <package ... externalReferenceResolver="spring"> > >>>>>> .... > >>>>>> <!-- NEW FEATURE : new node set --> > >>>>>> <externalRefrenceResolvers> > >>>>>> <externalRefrenceResolver name='spring' > >>>>>> class="SpringWebApplicationContextReferenceResolver"/> > >>>>>> <externalRefrenceResolver name='springXmlFile' > >>>>>> class="SpringClassPathXmlApplicationContextReferenceResolver"> > >>>>>> <param > name="filename">myApplicationContext.xml</param> > >>>>>> </externalRefrenceResolver > > >>>>>> </externalRefrenceResolvers> > >>>>>> .... > >>>>>> <action name='...' class='...'> > >>>>>> > >>>>>> <!-- NEW FEATURE : externalRefrenceResolver > attribute --> > >>>>>> <external-ref > externalRefrenceResolver='springXmlFile' > >>>>>> name='foo'>myFoo</external-ref> > >>>>>> <external-ref name='bar'>myBar</external-ref> > >>>>>> </action> > >>>>>> </package> > >>>>>> </xwork> > >>>>>> > >>>>>> this allows for reusing the same configured resolver > in multiple > >>>>>> packages - which you can do now, though without configuration. > >>>>>> this allows for each external-ref tag to optionally use a > >>>>>> different resolver as in the example above > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Ok that looks like it would work, I think we should declare > >>>>> resolvers the way you suggested. Though I don't think > we need then > >>>>> externalReferenceResolver attrib on the external-ref > element. We > >>>>> can just assume all actions in a package use the same > Resolver. I > >>>>> think it's neater that way; You can still use different > Containers > >>>>> on different packages to resolve your references and > there would > >>>>> be a more logical grouping of package/container. > >>>>> > >>>> I agree that is is not necessary to allow the resolver to be > >>>> overriden per external-ref though I think it could be a usefull > >>>> feature to have. Say you are using a thirs party spring based > >>>> component package - say for security - and you want > each action's > >>>> securityManager property to be resolved from this > context instead > >>>> of the package's one. > >>>> > >>>> I guess that another way of specifying it would be to use > >>>> > >>>> <external-ref name='foo'>springXmlFile:myFoo</external-ref> > >>>> > >>>> and to modify the interceptor to look for the : char. > >>>> > >>>> just my 2c worth ;) > >>> > >>> > >>> See your point, I guess we need to throw the notation up for > >>> discussion. > >> > >> > >> I don't really mind the syntax for specifying which > resolver to use. > >> > >> SO there are two questions > >> > >> 1. Do we need to be able to override the resolver on a per > refrence > >> basis 2. If we can override, what is the syntax ? > >> > >> Does anyone else have any thoughs or suggestions ? > >> > >>>> > >>>>>> I am sure that other frameworks will require some sort > of runtime > >>>>>> configuration for the external reference resolvers as well. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Any comments ? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> yep! > >>>>> > >>>>>> > >>>>>> Cameron > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Cheers, > >>>>> > >>>>> ross > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Thanks > >>>> > >>>> Cameron > >>>> > >>>>>> > >>>>>> Ross Mason wrote: > >>>>>> > >>>>>>> Cheers mate. > >>>>>>> > >>>>>>> I've just attached the SpringExternalReferenceResolver > >>>>>>> implmentation and tests to the Jira Issue. > >>>>>>> > >>>>>>> http://jira.opensymphony.com/secure/ViewIssue.jspa?key=XW-122 > >>>>>>> > >>>>>>> Ross > >>>>>>> > >>>>>>> Patrick Lightbody wrote: > >>>>>>> > >>>>>>>> This is good stuff -- not sure about a 1.0 release though. > >>>>>>>> We'll try to get a point release out shortly after though to > >>>>>>>> support this. > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: [EMAIL PROTECTED] > >>>>>>>> [mailto:[EMAIL PROTECTED] On > >>>>>>>> Behalf Of Ross Mason > >>>>>>>> Sent: Monday, November 17, 2003 8:02 PM > >>>>>>>> To: [EMAIL PROTECTED] > >>>>>>>> Subject: Re: [OS-webwork] [OS-xwork] Spring IoC integration > >>>>>>>> > >>>>>>>> I'll fix the commons dependancies first :-) > >>>>>>>> > >>>>>>>> Ross Mason wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> I've tried running the patch again (through > Eclipse) and I get > >>>>>>>>> the > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> same > >>>>>>>> > >>>>>>>>> problem - It only creates patch entries for new > files? I know > >>>>>>>>> this isn't a subject for this list, but does anyone > know why > >>>>>>>>> this happens? > >>>>>>>>> > >>>>>>>>> Anyway Cameron, I'll create a zip of the changes > for now and > >>>>>>>>> attach > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> it > >>>>>>>> > >>>>>>>>> to the the issue and this list. > >>>>>>>>> > >>>>>>>>> Cheers, > >>>>>>>>> > >>>>>>>>> Ross > >>>>>>>>> > >>>>>>>>> Cameron Braid wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> The patch seems to be missing code in the configuration > >>>>>>>>>> classes... since I have applied it, I am geting > compilation > >>>>>>>>>> errors : > >>>>>>>>>> > >>>>>>>>>> not defined : > >>>>>>>>>> > >>>>>>>>>> invocation.getProxy().getConfig().getPackageName() > >>>>>>>>>> invocation.getProxy().getConfig().getExternalRefs(); > >>>>>>>>>> packageConfig.getExternalRefResolver() > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> > >>>>>>>>>> Cameron > >>>>>>>>>> > >>>>>>>>>> Ross Mason wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> As per the discussion late last week, we have a patch for > >>>>>>>>>>> Xwork so that it can use an external container to resolve > >>>>>>>>>>> component > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>>> references. > >>>>>>>> > >>>>>>>>>>> I've created the following issue - > >>>>>>>>>>> > http://jira.opensymphony.com/secure/ViewIssue.jspa?key=XW-12 > >>>>>>>>>>> 2 > >>>>>>>>>>> > >>>>>>>>>>> I've added a breakdown of the changes below, in summary, > >>>>>>>>>>> this is how > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>> it works- > >>>>>>>>>>> > >>>>>>>>>>> You can configure a action to have external references in > >>>>>>>>>>> the xwork.xml using a new <external-ref> tag on the action > >>>>>>>>>>> > >>>>>>>>>>> When the action is configured the external refs > are stored > >>>>>>>>>>> on the action config. > >>>>>>>>>>> > >>>>>>>>>>> When the action is invoked, there is a new > interceptor that > >>>>>>>>>>> will resolve these references. It does this by > using a new > >>>>>>>>>>> attribute on the package config called > >>>>>>>>>>> externalReferenceResolver i.e. > >>>>>>>>>>> > >>>>>>>>>>> <package name="default" > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>>> > > > externalReferenceResolver="com.atlassian.xwork.ext.SpringServletContex > > tR > >>>>>>>> > >>>>>>>> eferenceResolver"> > >>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> In this case, the SpringServletContextReferenceResolver > >>>>>>>>>>> implementation will handle the work of looking up and > >>>>>>>>>>> setting the references on the action. Note, if a > resolver is > >>>>>>>>>>> not found on the actions package, it will > tranverse up the > >>>>>>>>>>> package heirarchy to find one. > >>>>>>>>>>> > >>>>>>>>>>> We have an implementation for Spring, but I have not > >>>>>>>>>>> included it in this patch as it should probably > go into an > >>>>>>>>>>> xwork-ext sub-project. Let me know what you want > me to do > >>>>>>>>>>> with this... > >>>>>>>>>>> > >>>>>>>>>>> Here are the changes and additions to the xwork codebase - > >>>>>>>>>>> > >>>>>>>>>>> 1. added 2 new config attributes - > >>>>>>>>>>> - a new element external-ref to the action element in the > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>>> config. > >>>>>>>> > >>>>>>>>>>> i.e <external-ref name="foo">Foo</external-ref> > where name > >>>>>>>>>>> is the setter method name and Foo is the reference to > >>>>>>>>>>> lookup. > >>>>>>>>>>> - added an attribute to the package element called > >>>>>>>>>>> externalReferenceResolver which supplies a FQ > classname to > >>>>>>>>>>> an ExternalReferenceResolver implementation. > >>>>>>>>>>> > >>>>>>>>>>> 2. Updated the xwork DTD accordingly. > >>>>>>>>>>> > >>>>>>>>>>> 3. Added 4 new classes - > >>>>>>>>>>> - External Reference - an encapsulation of the > external-ref > >>>>>>>>>>> tag > >>>>>>>>>>> - ExternalReferenceResolver - an interface to provide > >>>>>>>>>>> implementations for resolving references from an external > >>>>>>>>>>> container > >>>>>>>>>>> - ExternalReferencesInterceptor - will resolve > references on a > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>>> given > >>>>>>>> > >>>>>>>>>>> ActionInvocation > >>>>>>>>>>> - ReferenceResolverException - thrown by > >>>>>>>>>>> ExternalReferenceResolver > >>>>>>>>>>> > >>>>>>>>>>> 4. Added support for external references to the > >>>>>>>>>>> ActionConfig. I also > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>> added the attribute packageName to the > ActionConfig, so that > >>>>>>>>>>> the Interceptor could determine which package the action > >>>>>>>>>>> belonged to in order to find the > externalReferenceResolver. > >>>>>>>>>>> > >>>>>>>>>>> 5. Added support for the > externalReferenceResolver attribute > >>>>>>>>>>> to the PackageConfig. > >>>>>>>>>>> > >>>>>>>>>>> 6. Added support for the extra configuration to the > >>>>>>>>>>> XMLConfigurationProvider and DefaultConfigurationProvider > >>>>>>>>>>> > >>>>>>>>>>> 7. Added tests in the > >>>>>>>>>>> > org.opensymphony.xwork.config.ExternalReferenceResolverTest > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> I've attached a cvs patch with all the changes. > I built the > >>>>>>>>>>> patch against the latest src. > >>>>>>>>>>> > >>>>>>>>>>> Cheers, > >>>>>>>>>>> > >>>>>>>>>>> Ross > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> ------------------------------------------------------- > >>>>>>>>> This SF. Net email is sponsored by: GoToMyPC > >>>>>>>>> GoToMyPC is the fast, easy and secure way to access your > >>>>>>>>> computer from any Web browser or wireless device. > Click here > >>>>>>>>> to Try it Free! > >>>>>>>>> > >>>>>>>> > >>>>>>>> > > > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tm > > pl > >>>>>>>> > >>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Opensymphony-webwork mailing list > >>>>>>>>> [EMAIL PROTECTED] > >>>>>>>>> > https://lists.sourceforge.net/lists/listinfo/opensymphony-webw > >>>>>>>>> ork > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> ------------------------------------------------------- > >>>>>>>> This SF. Net email is sponsored by: GoToMyPC > >>>>>>>> GoToMyPC is the fast, easy and secure way to access your > >>>>>>>> computer from any Web browser or wireless device. > Click here to > >>>>>>>> Try it Free! > >>>>>>>> > > > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tm > > pl > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Opensymphony-webwork mailing list > >>>>>>>> [EMAIL PROTECTED] > >>>>>>>> > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwo > >>>>>>>> rk > >>>>>>>> > >>>>>>>> > >>>>>>>> ------------------------------------------------------- > >>>>>>>> This SF. Net email is sponsored by: GoToMyPC > >>>>>>>> GoToMyPC is the fast, easy and secure way to access your > >>>>>>>> computer from any Web browser or wireless device. > Click here to > >>>>>>>> Try it Free! > >>>>>>>> > > > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tm > > pl > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Opensymphony-webwork mailing list > >>>>>>>> [EMAIL PROTECTED] > >>>>>>>> > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwo > >>>>>>>> rk > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ------------------------------------------------------- > >>>>>>> This SF. Net email is sponsored by: GoToMyPC > >>>>>>> GoToMyPC is the fast, easy and secure way to access your > >>>>>>> computer from any Web browser or wireless device. > Click here to > >>>>>>> Try it Free! > >>>>>>> > > > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tm > > pl > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Opensymphony-webwork mailing list > >>>>>>> [EMAIL PROTECTED] > >>>>>>> > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwor > >>>>>>> k > >>>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Any damn fool can write code that a computer can understand... > >>>>>> The trick is to write code that humans can understand. [Martin > >>>>>> Fowler > >>>>>> > http://www.martinfowler.com/distributedComputing/refactoring.pdf] > >>>>>> > >>>>>> > ------------------------------------------------------- This SF. > >>>>>> Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy > >>>>>> and secure way to access your computer from any Web browser or > >>>>>> wireless device. Click here to Try it Free! > >>>>>> > > > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tm > > pl > >>>>>> _______________________________________________ > >>>>>> Opensymphony-webwork mailing list > >>>>>> [EMAIL PROTECTED] > >>>>>> > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> ------------------------------------------------------- > >>>>> This SF.net email is sponsored by: SF.net Giveback > Program. Does > >>>>> SourceForge.net help you be more productive? Does it help you > >>>>> create better code? SHARE THE LOVE, and help us help > YOU! Click > >>>>> Here: http://sourceforge.net/donate/ > >>>>> _______________________________________________ > >>>>> Opensymphony-webwork mailing list > >>>>> [EMAIL PROTECTED] > >>>>> > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > >>>>> > >>>> > >>>> > >>> > >>> > >>> > >>> ------------------------------------------------------- > >>> This SF.net email is sponsored by: SF.net Giveback Program. Does > >>> SourceForge.net help you be more productive? Does it help you > >>> create better code? SHARE THE LOVE, and help us help YOU! Click > >>> Here: http://sourceforge.net/donate/ > >>> _______________________________________________ > >>> Opensymphony-webwork mailing list > >>> [EMAIL PROTECTED] > >>> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > >>> > >> > >> > > > > > > -- > > Any damn fool can write code that a computer can understand... The > > trick is to write code that humans can understand. [Martin Fowler > > http://www.martinfowler.com/distributedComputing/refactoring.pdf] > > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. Does > > SourceForge.net help you be more productive? Does it help > you create > > better code? SHARE THE LOVE, and help us help YOU! Click Here: > > http://sourceforge.net/donate/ > > _______________________________________________ > > Opensymphony-webwork mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. Does > > SourceForge.net help you be more productive? Does it help > you create > > better code? SHARE THE LOVE, and help us help YOU! Click Here: > > http://sourceforge.net/donate/ > > _______________________________________________ > > Opensymphony-webwork mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us > help YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
