Re: [TRINIDAD] New element in trinidad-skins.xml /SkinImpl/SkinAddition

[Jeanne Waldman]

I need help understanding how you are expecting I use the MapELResolver/ResourceBundleELResolver, Adam. First, let me explain what I was doing. I was creating a ValueExpression when I parsed the trinidad-skins.xml and found a value in translation-source. // could be Map or ResourceBundle, so make the type Object return LazyValueExpression.createValueExpression(translationSourceExpression, Object.class); I store this ValueExpression on the skin. Then when getTranslatedValue is called, I would look up the key in the resource cache that I lazily build. A skin can have a bundle-name or it can have a translation-source, then if the translation isn't found, it looks in all the skin additions bundle-name or translation source, and then if it still isn't found it does the same thing for the base skin, on up the chain until it finds it. As I look into a map or resource bundle, I cache the entire map/resource bundle, to make subsequent lookups faster. To get the value from the translation source, I was planning to use the ValueExpression's getValue and then figure out if it is a ResourceBundle instance or a Map instance and proceed from there by caching the Map/ResourceBundle keys/values in mylocale cache, then getting the key's value, etc. --- I don't what you mean when you say I should use a ELResolver. I'm a novice with the ValueExpression, ELResolver code. I'm guessing from reading the javadoc that you mean create an ELContext that has a MapELResolver and another one for ResourceBundleELResolver. Then I figure out what type the ValueExpression is, and then I use that ELContext, and I take the 'key' in getTranslatedValue, and append that to the ValueExpression somehow (or store the _expression_ on the Skin as a String instead of a VE and use that as the 'base') and get the value. I suppose I can cache each key/value as I find it instead of caching the entire contents like I do for the bundle-name code. But I'd rather be consistent. Can you explain to me what you meant and iif/how that is better than the way I was planning to do it? Thanks! Jeanne Simon Lessard wrote: EL implies a small performance overhead but I guess it's acceptable for the gain here. On 9/21/07, Adam Winer < [EMAIL PROTECTED]> wrote: -1 to trying to turn everything into ResourceBundle.  Just use EL - ELResolver in 1.2, PropertyResolver in 1.1.  As of 1.2, that gives you ResourceBundle and Map support.  In 1.1, only Map (and bean, of course), but then again in 1.1 how do you get unwrapped ResourceBundle instances into EL anyway? @Gary:  the Shale LoadBundle class seems quite unnecessary in 1.2, right? -- Adam On 9/21/07, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > >From: "Simon Lessard" <[EMAIL PROTECTED]> > > > > > > > >If we accept only a map, it's quite exclusive, unless we add yet another > tag, but I would be -1 on >that. However, as Adam suggested, we could call > it "translation-source" and support both Map and >ResourceBundle instances. > We have to a very thin adapter Map --> ResourceBundle if a Map >instance is > passed and the remaining code will continue to work as it's now, with a > ResourceBundle. > > > FWIW, Shale has a utility class that sounds very similar to what you have > described [1]. > > > [1] > http://svn.apache.org/viewvc/shale/framework/trunk/shale-core/src/main/java/org/apache/shale/util/LoadBundle.java?view=markup > > > > > > >~ Simon > > Gary >