struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Geary <sabrew...@gmail.com>
Subject Rép : [shale] Proposal: making view controllers easier to access
Date Fri, 30 Dec 2005 23:22:20 GMT
 Le 30 déc. 05 à 08:18, Gary VanMatre a écrit :

>
> From: Laurie Harper <laurie@holoweb.net>
>
> 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.


I like this idea, and as Gary points out below, Clay gives us the facilities
to implement it. 8-)

In Rails, btw, you can access the controller in your views with a variable
named controller. It turns out to be quite handy and makes your views easier
to read.


david


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 "@managed-bean-name" 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message