Hi guys, so since there are no other objections, i a gonig to attach my patches that i have done to fulcrum parser und fulcrum upload to http://issues.apache.org/jira/browse/TRB-32 for your kind review. I have made lots of modifications to ensure that the parser works the same as in t2.3.2 as i understood Scott, that that is what we would want. I had to extend the fulcrum-upload component to expose getAutomatic() as this was needed by the t2.3.2 parser If this is wrong, let me know. I will now start working on fulcrum-intake.
Hopefully we will be able to release thaose components then. Kind regards Juergen Hoffmann ---------- Weitergeleitete Nachricht ---------- Subject: LONG: working on the parser Date: Donnerstag, 6. Juli 2006 01:16 From: Jürgen Hoffmann <[EMAIL PROTECTED]> To: turbine-dev@jakarta.apache.org Hi Guys, after studying a lot of avalon and components and existing codebase, i have come to a point where I have some questions about the parser. Well DefaultParameterParser, DefaultCookieParser, StringValueParser all extend BaseValueParser. Now BaseValueParser implements (I)ValueParser. ValueParser is extended by (I)ParameterParser and (I)CookieParser. Other than those we have the CSV- and TSVParser which extend DataStreamParser and hence really have nothing to do with the component, as they could parse any fixed Value DataStream... Now to my question. Do we really want one jar file for all possible Parsers and create a new Interface for the CSV/TSVParser and have then 4 components inside one jar file, or do we want to split this up further inside fulcrum-baseparser fulcrum-parameter-parser fulcrum-cookie-parser fulcrum-string-parser fulcrum-csv-parser have those components implement contextualizable, and make them lookup fulcrum-baseparser? Another thing is that we have ParserUtils inside t2.3.2. ParserUtils check the TR.props for the desired folding. Now in Trunk there is a ParserUtils, but we do not want to use it, because this creates a dependency upon turbine, which is surely not what we want. So to come by this, I made DefaultParameterParser implement Configurable, and added the necessary Methods (convertAndTrim) to the ValueParser Interface. Now why in there, and not to (I)ParameterParser? Because BaseValueParser has a method convert(String) which calls convertAndTrim(String). Henning solved this by creating the ParserUtils class, which was a basic Utility Class providing static Methods. Now because of the aforementioned probable dependency, I am asking what would be best. Keep ParserUtils, and create another static Method to set the desired UrlCaseFolding Value during Configuration of the Component, or keep it inside the Interface ValueParser? Other than that my work of Migrations is fairly done. After you guys decided on what to do, I will create a patch for your review. Should we at least create different packages for the Parsers that are dependant on BaseValueParser and those dependant on DataStreamParser? Please let me know what you think. -- Kind regards Juergen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] !EXCUBATOR:1,44ad026b48531401014216! ------------------------------------------------------- -- Kind regards Juergen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
