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. > >> > >>Scott > >> > >>-- > >>Scott Eade > >>Backstage Technologies Pty. Ltd. > >>http://www.backstagetech.com.au > >> > >> > >> > >> > >> > >>------------------------------------------------------------ > --------- > >>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] > > > > > > > > > > > > > > --------------------------------------------------------------------- > 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]
