I am looking at this code for the AbstractMapDecorator and two questions come up..
1) This is not in the 2.1 version, correct? This is in a CVS head version? 2) How does this simplify what I would have to write...? Since the decorator decorates a Map, I would still have to write an adapter between parameterparser and map, correct? I think I need a ParameterParserMapAdapter class that takes in a parameterparser (value parser?) and implements the Map interface to be passed into the Intake code...? Eric > -----Original Message----- > From: Daniel L. Rall [mailto:[EMAIL PROTECTED] > Sent: Friday, September 26, 2003 10:35 PM > To: Turbine Developers List > Subject: Re: cvs commit: jakarta-turbine-2/xdocs changes.xml > > > Regarding the HashMap, it would be much cheaper to use a Map > decorator to wrap > an existing instance of ParameterParser. Jakarta Commons Collections > AbstractMapDecorator [1] would make this easy to implement. > > [1] > http://cvs.apache.org/viewcvs.cgi/jakarta-commons/collections/ > src/java/org/apache/commons/collections/decorators/AbstractMap > Decorator.java?rev=1.3&content-type=text/vnd.viewcvs-markup > > Eric Pugh wrote: > > I just finished the commit. Do you want to take the ball > on trying to get > > the hashmap out of the parameter parser? > > > > I don't actually use intake, but it seems like many things > rely on intake, > > so I had to get it over to fulcrum before implementing it > into turbine. For > > instance, the converting localization to fulcrum doesn't > work without > > converting to intake in fulcrum as well! > > > > Eric > > > > > >>-----Original Message----- > >>From: Colin Chalmers [mailto:[EMAIL PROTECTED] > >>Sent: Friday, September 26, 2003 12:50 PM > >>To: Turbine Developers List > >>Subject: Re: cvs commit: jakarta-turbine-2/xdocs changes.xml > >> > >> > >>I have a first cut of Intake running as a Fulcrum Component.. > >>However, I > >> > >> > >>>don't have your changes yet. I would like to commit it > >> > >>today for review. > >> > >>>Colin, since you seem to understand Intake a lot, would you > >> > >>review the > >> > >>>changes I have made and I think that your refactoring for > >> > >>2.4 should be made > >> > >>>in the fulcrum component, and the intake in 2.3 will be > >> > >>deprecated. If you > >> > >>>are making things easier, then that will provide a clear > incentive to > >>>switch. > >>> > >> > >>Cool, but I have to admit that the IntakeService still holds > >>some grey > >>areas for me. > >> > >> > >>>The intake service in fulcrum leverages the localization > service from > >>>fulcrum as well! > >>> > >>>The only difficulty I have is on the parameterparser and > >> > >>valueparser. They > >> > >>>require a reference on Turbine 2.3. Since I want to use the intake > >>>component in a standalone use case, as well as using it with > >> > >>Scarab which > >> > >>>uses Turbine 3.0. > >>> > >>>So, what would be requried to ditch the > >> > >>paremeterparser/valueparser? While > >> > >>>we could move them to fulcrum, in many ways they seem to > be very http > >>>request specific, and ought to not be used in Fulcrum. > >>> > >> > >>Yeah as far as understand it Fulcrum shouldn't have any > >>dependancies on > >>HTTP stuff right? I think Parameterparser just contains a > >>hashMap of the > >>data we need, if we could extract the HashMap from > >>Parameterparser and > >>pass that to the Fulcrum version (of Intake) we could extract the > >>required data from there? > >> > >>Colin > >> > >> > >>>Comments? > >>> > >>>Eric > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Scott Eade [mailto:[EMAIL PROTECTED] > >>>>Sent: Friday, September 26, 2003 3:20 AM > >>>>To: Turbine Developers List > >>>>Subject: Re: cvs commit: jakarta-turbine-2/xdocs changes.xml > >>>> > >>>> > >>>>Colin Chalmers wrote: > >>>> > >>>> > >>>> > >>>> > >>>>>I want to refactor some intake stuff to make it simplier to > >>>>>understand, this will be going into the 2.4 release. Will > >>>>> > >>>>> > >>>> > >>>>probably be > >>>> > >>>> > >>>> > >>>>>running a few things by you for feedback if you don't mind. > >>>>> > >>>>> > >>>> > >>>>You seem > >>>> > >>>> > >>>> > >>>>>to be using the Intake service quite intensly? > >>>>> > >>>>> > >>>> > >>>>Fine, but if you want me to try anything I will most likely > >> > >>only have > >> > >>>>applications running on 2.3.1-dev, not 2.4-dev. > >>>>If you search way back in the mail archives you can find > >>>>reference to an > >>>>extension to Intake that provided client side validation using > >>>>JavaScript. JavaScript would be no substitute for > validation on the > >>>>server, but it could improve the user experience. It could be > >>>>interesting to integrate this if you have some time on your hands. > >>>> > >>>> > >>>> > >>>> > >>>>>Let me know if 2.3.1 Intake is now performing as expected. > >>>>> > >>>>> > >>>> > >>>>AFAIK the only outstanding problem relates to the use > format of the > >>>>values returned by DateString. I am avoiding this by not > >>>>using DateString. > >>>> > >>>>Thanks for your patch - it saved me digging deeper into > >> > >>Intake than I > >> > >>>>already have. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
