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
> > >
> >
>
>

Reply via email to