Thank you for the clarification Oliver, now I see and I like it. Now, to get back to where this code should live: I do like the idea of having a class for this feature (and the one interface). We now have text.Interpolation. I've never been crazy about the name and looking at the JRE (1.4.2), there is a java.text.MessageFormat that is similar in intention, the JRE format classes only work with indices, not names.
If we can agree that this code should live in its own class, I would like to propose o.a.c.l.text.VariableFormat (or a similar *Format name). Then we'd have a nicely named pair text.VariableFormat and text.VariableResolver. Thoughts? Gary -----Original Message----- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 28, 2005 10:56 AM To: Jakarta Commons Developers List Subject: Re: [lang] text.Interpolation, on to 2.2 Emmanuel Bourg wrote: > Gary Gregory wrote: > >> - For [config]: Provide an Interpolation feature that it can build on. >> The [config] project, please correct me if I am off, must have a way to >> plug-in how to look stuff up, hence the nice and simple VariableResolver >> interface, which could be surfaced as: >> >> String s = XXX.resolveAll(source, ..., aVariableResolver); >> >> There is also a [config] need for multiple VariableResolvers it seems, >> which means that the API can take a Map of VariableResolver or that the >> client simply calls the API until all resolve calls worked. But how do >> you determine that an API call resolved everything? If one cannot >> (Oliver?), then we have to provide a resolveInAll(String, Map) (or other >> name)? > > > And what about some kind of chained VariableResolver ? A resolver that > will check several resolvers or use a specific resolver depending on > the key ? Thus there is no need to have several resolveAll methods and > the actual strategy is delegated to the resolver. > > Emmanuel Bourg > Yes, this is exactly what I meant by "Then I could pack the logic I had before in my Interpolation class (support for different variable resolvers, default variable resolver etc.) into a special implementation of this interface." The idea is to somehow associate variables with a concrete resolver. As an example, an input could look like: "File ${x:fileName} was stored in ${sys:user.home} at ${e:now}" Then there would be a composite or chained variable resolver that would know, which of its child resolver to use for the different variables. So the API in [lang] can remain simple and complex logic can be put in specific implementations of the VariableResolver interface (which would live in other projects). Oliver --------------------------------------------------------------------- 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]
