Craig McClanahan wrote:
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.
You're talking about using annotations to drive the mapping manager,
right? Yeah, I can see how that would be useful in a different context,
but I don't think it applies here (see below).
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.
OK, now I understand the issue.
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 ...
Yeah, I didn't think it through. I'm fine with the current mechanism for
resolving a view ID to a controller instance.
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.
Right, I think we're more or less on the same page now ;-) A custom
variable resolver sounds like it might be a reasonable way to go.
There'd need to be some way for it to be aware of the current
view/subview so it could resolve the name 'backing' the the view
controller for the current view.
Actually, it's even simpler than that: assuming the VR can determine the
view ID for the current (sub)view, all it needs to do is use the same
mapping manager as ShaleViewController did to translate a request for
'backing' into a request for the right bean.
Hopefully Gary will chime in on the question below for how Clay manages
this.
L.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
