Mailing-List: contact issues-help@shale.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@shale.apache.org
Message-ID: <9217878.1173891051241.JavaMail.jira@brutus>
Date: Wed, 14 Mar 2007 09:50:51 -0700 (PDT)
From: "Craig McClanahan (JIRA)" <jira@apache.org>
To: issues@shale.apache.org
Subject: [jira] Commented: (SHALE-425) ViewControllerMapper allows mapping
 only to one bean
In-Reply-To: <4759256.1173876111420.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/struts/browse/SHALE-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40557 ] 

Craig McClanahan commented on SHALE-425:
----------------------------------------

> ViewControllerMapper.mapViewId(String viewId) allows only to map a view to a single bean. A key feature of JSF (IMHO)
> is the ability to have multiple backing beans / view controllers that contribute to a single page. An extension of this interface
> could allow other mapping strategies to associate multiple beans with a given page that can then receive phase change
> events. A possiblte mapping strategy would be a XmlViewControllerMapper which takes a XML file that associates view
> ids with bean names.

Interesting idea.  From my viewpoint, the view controller mapping is primarily a mechanism to use "convention over configuration" to identify a managed bean that should receive application related events that are associated with a view.  In no way are you limited to binding *only* to this particular bean in our view -- you can use value binding expressions to bind to data from lots of different beans.  Given this, I am a believer in the philosophy that all the event handlers for a particular view should be together in the same managed bean, which minimizes the number of different places a developer has to look at.

If there were more than one output of view controller mapping, on which bean should events like init(), preprocess(), prerender(), and destroy() be called?  All of them?  Only those that implement ViewController?  Only the first one?  All I can see coming out of this is confusion.  Can you help me understand what kinds of benefits you are looking for by having this?

Note that you can already use abstract superclasses to provide shared handling methods for commonly implemented actions.  Indeed, we offer a convenience abstract base class (AbstractViewController) which you can extend, and leverage shared functionality.  A common strategy is to build your own convenience base classes that add shared application specific actions (and helper methods), and then have your actual view controller beans extend that.


> ViewControllerMapper allows mapping only to one bean
> ----------------------------------------------------
>
>                 Key: SHALE-425
>                 URL: https://issues.apache.org/struts/browse/SHALE-425
>             Project: Shale
>          Issue Type: Improvement
>          Components: View
>    Affects Versions: 1.0.4
>            Reporter: Matthias Wuttke
>            Priority: Minor
>
> ViewControllerMapper.mapViewId(String viewId) allows only to map a view to a single bean. A key feature of JSF (IMHO) is the ability to have multiple backing beans / view controllers that contribute to a single page. An extension of this interface could allow other mapping strategies to associate multiple beans with a given page that can then receive phase change events. A possiblte mapping strategy would be a XmlViewControllerMapper which takes a XML file that associates view ids with bean names.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.