>From: Laurie Harper <[EMAIL PROTECTED]>
>
> 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 there situations that would make this a Really Bad Idea? I'm
> wondering if it might cause issues for view composition with Clay, for
> example.
>
Clay handles the aliasing of managed bean names associated with reusable view
fragments using symbols. The symbols sit on top of the EL and are evaluated
before the binding object is created. This is a key reuse feature in clay. It
allows you the freedom to create a dictionary of reusable visual composition
elements.
Symbols are identified by the @ character which is the prefix delimiter.
The idea of symbol replacement started with only the managed bean name but grew
into a more global application. Symbols can be defined from the XML component
definitions or from HTML elements.
The XML method is obvious but in HTML, symbols are defined by html attributes
that don't have a corresponding component definition. Symbols are scoped
vertically within the document meaning that aggregated\nested components
inherit symbols from their parent. Symbols can be overridden at any level
within the composition.
If you are using the clay:clay jsp tag to add composition to a jsp page, you
explicitly set it using the managedBeanName attribute of the jsp tag. You can
also use the clay:symbol tag nested in a clay:clay tag.
<clay:clay jsfid=addressPanel managedBeanName=page$widgets>
<clay:symbol name=managed-bean-name value=page$widgets/>
</clay:clay>
The symbol [EMAIL PROTECTED] has implicit meaning if you are using full html
views. This means that your are using an html template as the entry point.
Full html views require a custom view handler that uses the same managed bean
mapping facility built into Shale
(org.apache.shale.view.impl.DefaultViewControllerMapper). Since it uses the
same mechanism for normalizing the view controller managed bean name from the
view id, a custom implementation of the ViewControllerMapper interfaces would
plugged right into Shale and Clay.
> 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.
Gary
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
