commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@t-online.de>
Subject Re: [lang] VariableFormatter and text package
Date Wed, 08 Mar 2006 17:15:34 GMT
(Man, I was offline for two days and now getting drowned in a flood of
mails!)

Gary Gregory wrote:

>Hello:
>
>Personally, I like the VariableFormatter class and plan on using it in
>production. For me, this class is what is motivating me to push for a
>2.2 release (3.0 seems like release inflation ;)
>
>I agree that VariableFormatter appears complex, but that is OK to me
>given the flexibility it provides. In addition, it works for some fancy
>cases as demonstrated in the unit tests.
>  
>
Yes, the main reason for its complexity (aside from my humble
programming skills) is that this class also provides some features that
go beyond a simple replace solution, e.g. detecting of cyclic
substituitions, escaping of variables, and the possibility of injecting
your custom variable resolver. This is stuff I would like to use in
[configuration]. If anybody provides a less complex solution that offers
the same features I would certainly welcome it.

Such a simple replace operation Stephen mentions below is probably easy
enough to implement, but will certainly miss some of the features we
have now. I hoped we could provide something more powerful.

About StrBuilder: Wouldn't it be easy to add another overloaded
replace() method, which takes a StrBuilder as argument? This method
would obtain the builder's content as char[], perform the replace
operation, clear() the builder and then append() the result. Or a
different approach would be to add some replace() (or substitute())
methods to StrBuilder, which would call corresponding VariableFormatter
methods.

>I recall vaguely being involved in the class' integration into [lang] so
>I am happy to talk about it. 
>
>If the original author, Oliver Heger, is here, please feel free to pipe
>in. I found Oliver very flexible and easy to deal with in the past :)
>  
>
Thanks!

>  
>
>>I just wonder if we should rewrite the class much more simply <snip>
>>    
>>
>
>If someone does this, I would humbly suggest that we refactor with
>interfaces such that, at least for development, we can plugin the new
>implementation and see if the same tests still pass.
>
>WRT using StrBuilder, I like the idea of eating our own dog food but I
>would only do so in this case if there is a real point in doing so. I
>could be wrong ;)
>
>Gary
>
>  
>
>>-----Original Message-----
>>From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
>>Sent: Tuesday, March 07, 2006 3:04 PM
>>To: Jakarta Commons Developers List
>>Subject: [lang] VariableFormatter and text package
>>
>>This class is my main hold-up for release 2.2. Somehow, I just don't
>>like it. It seems way complex for what it appears to do.
>>
>>Thats a gut feel reaction however - I can't get my head around the
>>    
>>
>code
>  
>
>>easily (another negative).
>>
>>More specifically, there is no way to substitute the variables in a
>>StrBuilder, which is kindof the point of the package.
>>
>>I just wonder if we should rewrite the class much more simply,
>>    
>>
>allowing
>  
>
>>it to operate on a StrBuilder. Isn't it just a loop through a map
>>    
>>
>doing
>  
>
>>a search and replace on ${key} -> value ?
>>Not sure how others feel about the class.
>>
>>
>>The other item in the text package is StrBuilder.asTokenizer(). This
>>method does not cuurrently actually link the tokenizer to the builder
>>(as the writer/reader do). I think that what should happen is that the
>>following sequence should work:
>>
>>Create and populate StrBuilder
>>Call asTokenizer()
>>Tokenize
>>Add text to the builder*
>>Call StrTokenizer.reset()
>>Tokenize (and get results including added text*)
>>
>>Stephen
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>    
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message