On 12/29/05, Laurie Harper <[EMAIL PROTECTED]> wrote:
>
> One thing I'm finding a little ugly using Shale is referencing the view
> controller using EL expressions. Due to the way Shale maps view IDs to
> backing bean names, I end up with ugly EL expressions like
> #{pages$user$profile$general.whatever}.
>
> Would it make sense to store the view controller under a well-known
> (configurable) key, so you could instead write #{backing.whatever}?
> Shale could use a standard name (e.g. 'backing') by default and provide
> a configuration option to change this to whatever the developer wants.
>
> There could also be a mechanism for setting the 'alias' on a per-view
> basis; perhaps an interface the view controller bean can optionally
> implement which would return the backing bean alias and/or allow it to
> be set as a managed property.Are you thinking of something that would let the *bean* say what *page* it is the controller for (rather than the other way around, as you currently do)? That would probably be feasible -- especially in the optional Shale Tiger library, where we could use annotations for that purpose. However, the text of your views (in particular, the value binding expressions in your components) are going to *have* to know the managed bean name of the corresponding backing bean anyway. So, it doesn't seem like it would add a lot of value. Are there situations that would make this a Really Bad Idea? One scenario where sharing a common request scope attribute would create a limitation (versus current behavior) is you would not be able to have more than one active view controller on a page. With subviews, it is convenient to have a view controller per Tile, for example. If you don't like the current mapping algorithm, by the way, you're free to change it :-). Simply create your own implementation of ViewControllerMapper and register it (in application scope) under the key identified by ShaleConstants.VIEW_MAPPER. I'm > wondering if it might cause issues for view composition with Clay, for > example. I don't think any of the mapping issues care what view technology you are actually using, although Clay does provide a mechanism to do substitutions on the "@managed-bean-name" symbol for you when it constructs the page. Assuming there aren't major drawbacks to the idea, I'll try and work up > a patch in the next day or so covering some or all of the points above. > > Cheers, > > L. Craig
