From: "Adam Murdoch" <[EMAIL PROTECTED]> > > I would like to call upon a vote for the promotion of > > the FilterReaders proposal from the sandbox to the main > > development tree. > > > > +1 - very cool. >
Thank you! > I have some tiny nitpicks, however: They are welcome. > > * Can you split up ChainReaderHelper.processStream() into two methods: A > method that assembles the Reader, and a utility method turns a Reader into a > String (this method would fit better on FileUtils). You also might want to > use a StringBuffer when you're doing the conversion. I considered that - can recollect why I trashed it before. I will provide one. > > * Why does LoadProperties parse the properties? Why not use > java.util.Properties? Thinking out aloud - How? By converting inputreader to inputstream? hmm... > > * Should BaseFilterReader.skip() be using this.read() > rather than in.read()? Yep. If in.read() is used, a skip of improper number of characters will be done. > > * You might want to look at refactoring some of the common(-ish) stuff from > the filters down into BaseFilterReader. For example, nearly all of the > filters deal with lines of text, and each has their own 'read a line from > the file' code. It would be better if BaseFilterReader (or an intermediate > LineFilterReader class) took care of this for the filters. Same with > setParameters(), setInitialised(), getInitialised(), etc. And dealing with > buffering. ok. > > * Any chance of a filter that adjusts end-of-line characters? How about a > regexp version of LineContains? > There you go :-) Looking for a replacement for FixCRLF, eh? As far as regexp version of linecontains, it is just a question of time... > > Adam > Cheers, Magesh *********************************************** * He who won't take responsibility for his * * mistakes is usually the first one to point * * a finger at someone else's. * *********************************************** -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
