On 12/31/05, Laurie Harper <[EMAIL PROTECTED]> wrote:
>
> Craig McClanahan wrote:
> > 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.
>
> Eep! No :-) I meant a way for the bean to say what 'value binding alias'
> it should be exposed under. So ShaleViewController would create a value
> binding that allowed the controller to be refered to a
> #{backing.whatever} by default, but a particular controller bean could
> cause something other than 'backing' to be used.
The tiger extension stuff can do that, but (since it is really using JSF
managed beans under the covers) there could still only be one bean class for
a particular alias, using the current mapping architecture. Thnking about
it some more, that means you can't even achieve sharing a particular
attribute key for all the view controllers at all -- the way things are
architected today -- even by replacing the ViewControllerMapper.
>> 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.
>
> Hmm, I don't know about 'subviews' yet :-) But I think I get the point;
> if you have more than one view (JSP etc.) rendered as part of a single
> request, the view controllers would 'collide' using this idea, is that it?
Yep.
Does JSF support page scope? I'm guessing not, as that's a JSP-specific
> concept.
That's right ... it applies to JSP only.
> 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.
>
> Given the above limitation, that might be a better idea then.
Except it won't give you what you want :-(. That would take a different
sort of mapping approach, which might require something other than managed
beans to actually create the beans in question, which is kinda going away
from the original direction ...
> 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.
>
> To be clear, I wasn't proposing changing the existing mapping mechanism
> at all, only augmenting it such, that *in addition to* referencing
> #{foo$bar$baz.whatever} as you can you, you could also write
> #{backing.whatever}.
Now that might be a more interesting alternative ... change the custom
variable resolver's mechanism for figuring out what "backing" means ... then
it could work for Clay or non-Clay view rendering.
How does Clay resolve the conflict you described above to resolve
> @managed-bean-name correctly when used with subviews? Could the same
> strategy work outside of Clay, or is it too deeply bound up in Clay's
> render model?
Gary?
L.
Craig
> 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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
