struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandre Poitras <alexandre.poit...@gmail.com>
Subject Re: Rép : [shale] Proposal: making view controllers easier to access
Date Sat, 31 Dec 2005 03:40:17 GMT
But a more general use of symbols could be hard with the presence of
this *bug* I filled sometimes ago. Don't want to be silly, but it is
still a concern I face when I am using Clay.
http://issues.apache.org/bugzilla/show_bug.cgi?id=37792

So with 26 letters (I think symbols are not sensitive to case) + ten
numbers, you end up with the possibility to use only 36 symbols wich
is not a lot.

Am I right?

On 12/30/05, David Geary <sabreware@gmail.com> wrote:
>  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
> >
> >
> >
> >
>
>


--
Alexandre Poitras
Québec, Canada

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message