Ok, this all sounds good! I think it would be reasonable to have a String version of the resolve API to make the most common case easy to deal with. Perhaps the generic Object API would be "Object resolveObject()" while the more normal (for [lang].text) String version be "String resolve()"?
Gary -----Original Message----- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Monday, June 27, 2005 10:30 AM To: Jakarta Commons Developers List Subject: Re: [lang] text.Interpolation, on to 2.2 Hello Gary, I have no strict definition of what I call an interpolation engine, but I view it as somewhat that is customizable by clients. What is already implemented in [digester] would to a major part satisfy the needs of [configuration]. In addition to the basic interpolation functionality we would like to have - the VariableResolver concept allowing a user to define a custom set of sources for variable values, - support for multiple VariableResolvers at the same time (e.g. by using certain prefixes for the variables to associate them with a resolver), - a default VariableResolver, which will be called for all variables that are not associated with a specific resolver; the configuration object itself will act as this default resolver maintaining backwards compatibility with the current interpolation implementation (ATM the values of configuration properties can be variables, which will be replaced by the values of the properties in the same configuration object they refer to). The code in the bugzilla ticket is different from [digester] in the following points: - The VariableResolver interface returns an Object as a variable's value. [digester]'s pendant has a String. Because [configuration] supports different data types by default I thought plain Objects would be more appropriate and would avoid unnecessary type conversions. - For the same reason the main interpolation method returns an Object rather than a String, too. - The prefixes that associate a variable with a VariableResolver are a bit different (but this is a matter of taste). - The main interpolation method is extracted from AbstractConfiguration. It is able to detect cyclic variable replacements and throws an exception with a nice stack trace in these cases. I don't know how this is implemented in [digester]. Oliver Gary Gregory wrote: >Hello: > >I think that a good motivation for interpolation in [lang] would be to >have [configuration] as a call site ([configuration] already depends on >[lang]). With that in mind, I would like to see interpolation classes >suitable for [configuration] but not any more complicated for a first >cut. > >"I am reluctant to implementing a complete interpolation engine in this >project and expose it in the public API." > >I would like us to take an XP approach first by implementing just what >[configuration] needs for example, not a complete engine. > >You mention [digester]; does it have what you would call a "complete >interpolation engine"? Do you have a definition of what such a best >features? What are the differences b/w the code in the ticket and a >complete engine or the one in [digester]? > >Thanks, >Gary > > >-----Original Message----- >From: Oliver Heger [mailto:[EMAIL PROTECTED] >Sent: Monday, June 27, 2005 1:08 AM >To: Jakarta Commons Developers List >Subject: Re: [lang] text.Interpolation, on to 2.2 > >Gary, > >that's right, the basic idea is to configure several VariableResolvers >for different purposes. This is pretty much the same as the >interpolation engine of [digester] works. Resolvers for system >properties and map based resolvers are very obvious and simple >implementations. But a VariableResolver could be arbitrary complex, e.g. > >a JEXLResolver for expressions (maybe not directly suited for [lang]). > >Interolation is an important feature of [configuration], but I am >reluctant to implementing a complete interpolation engine in this >project and expose it in the public API. So I would love to see >something like that in [lang]. > >Oliver > >Gary Gregory wrote: > > > >>Hello Oliver: >> >>I took a quick look at the ticket you linked to below. For this to work >>for System properties, a simple VariableResolver would do the trick I >>think. Maybe a generic MapVariableResolver could also be provided and >>maybe a factory methods in order to say simple things like: >> >>Interpolator.newInterpolator(System.getProperties()).resolve("The file >>is here ${java.io.tmpdir}"); >> >>Would [configuration] be interested in have this in the next version of >>[lang]? Assuming that whatever loose requirements created by the >> >> >current > > >>lang tests are satisfied. >> >>Gary >> >>-----Original Message----- >>From: Oliver Heger [mailto:[EMAIL PROTECTED] >>Sent: Saturday, June 25, 2005 7:46 AM >>To: Jakarta Commons Developers List >>Subject: Re: [lang] text.Interpolation, on to 2.2 >> >>I am interested in this topic, too, because I want to implement >> >> >enhanced > > >>interpolation suport for [configuration]. >> >>I already had a look at the available Interpolation class, but it lacks >> >> > > > >>some features I need. So I wrote something myself which is similar to >>the interpolation engine of digester, but is based on the interpolation >> >> > > > >>method that existed in configuration. The code and a unit test can be >>found at the following bugzilla ticket: >> >>http://issues.apache.org/bugzilla/show_bug.cgi?id=35116 >> >>Oliver >> >> >> <snip> --------------------------------------------------------------------- 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]
