[1] http://cvs.apache.org/viewcvs.cgi/jakarta-commons/collections/src/java/org/apache/commons/collections/decorators/AbstractMapDecorator.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]
