I talked to him about this on ICQ actually. It does make it more flexible and powerful, but also more complex. I'm not sure that complexity is needed (even Cameron himself says he doesn't need it), so can we add it when/if someone requests it? :)
As for the resolver resolving one reference at once, I'm not sure I like that either. You should leave the resolution logic up to the Resolver class not the Interceptor IMHO, so you can do things like <external-ref ref="all" /> and your customer resolver class then knows to resolve _all_ references. Overall though, the init params etc work just like the rest of WW, so as long as they're all optional (and it works with just one resolver and simple references) I don't really mind as I can keep my side simple. My $0.02 :) M On 13/12/03 3:42 AM, "Jason Carreira" ([EMAIL PROTECTED]) penned the words: > 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 ------------------------------------------------------- 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
