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

[Jeanne Waldman]

Ahh, now I see. And now this part of the Java EE 5 Tutorial makes sense: "All of the standard and custom resolvers available to a particular application are collected in a chain in a particular order. This chain of resolvers is represented by a CompositeELResolver instance. When an _expression_ is encountered, the CompositeELResolver instance iterates over the list of resolvers and consults each resolver until it finds one that can handle the exception." I can see what you mean now, so that's good. :) However, I still want to implement it my way because * I potentially have to check lots of places - skin additions, base skins etc for the key, and I'll get a lot of misses until I find and cache it if I do it your way; I won't if I do it my way. * With Blake's help/review I had recently rewrote the caching mechanism to be faster, in that it gets the entire resource bundle and caches all the keys/values. It stops once it finds the key/value, and keeps track of the last resource bundle it checked and resumes from there if the next key is not already cached. If I do it my way - read the entire Map or ResourceBundle, cache into a locale->key/value map, then return the value, then it is faster.  We can talk offline about the implementation details if you want. Thanks, Jeanne Adam Winer wrote: 1. Evaluate the base ValueExpression (without looking at the string or anything like that). Call this object "base". Call the property "propertyName". 2. Get the ELResolver from Application and the ELContext from FacesContext 3. Call elResolver.getValue(elContext, base, propertyName); You don't need to get types, or do instanceof, or anything like that! -- Adam On 9/24/07, Jeanne Waldman <[EMAIL PROTECTED]> wrote: 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