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.
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?
Does JSF support page scope? I'm guessing not, as that's a JSP-specific
concept.
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.
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}.
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?
L.
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]
