Re: [shale] Proposal: making view controllers easier to access

[Laurie Harper <la...@holoweb.net>]

Craig McClanahan wrote:
> On 12/31/05, Laurie Harper <la...@holoweb.net> wrote:
>> Craig McClanahan wrote:
>>> On 12/29/05, Laurie Harper <la...@holoweb.net> 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: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
> 


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