Hi all, 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.
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. 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]
