[
https://issues.apache.org/struts/browse/SHALE-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40570
]
Craig McClanahan commented on SHALE-425:
----------------------------------------
> Thank you very much for your responses. First: Should I have posted my
> suggestion to a mailing list or is it ok to discuss such things here?
Either way works for me -- since you were making a specific enhancement
suggestion, logging it as an issue first ties all related information together.
The downside is that nobody on the user list will generally see it, and be
able to comment on their own thoughts, unless they happen to be browsing the
issue tracking system.
> I think it is not confusing to have multiple view controllers, each of them
> with separate responsibilities. Imagine a "treeController" that is able to
> handle a navigation tree (load data for the tree component, respond to
> events, etc.) and a "detailController" that deals with the form displayed
> besides the navigation (saving form data using Hibernate, etc.). Both of
> them might need prerender() methods, for example to load data for list
> items after the other form fields have been validated and applied to the
> model and before the page gets rendered. Both of them seem to have
> "equal rights" for being the "main" controller. Of course I could just create
> a single main backing controller bean that just returns these two beans,
> but it did not seem to be a big deal for me to allow multiple controllers
> being
> mapped per page.
This sounds like a great place to use subviews. Each subview can itself
associated with its own view controller bean, and therefore have its own event
handlers. See the <s:subview> TLDdocs for more info. The content inside
<s:subview> can be normal JSP content, or you can use something like
<jsp:include> to reuse a shared fragment in a separate file.
> This is especially because I personally do not like the to default naming
> the Shale View imposes on me for my controllers (being a big fan of
> "convention over configuration, though): I think "admin$compactDisc_list"
> is far too long for a bean name, and I think template names should be
> allowed to contain a "-" like in "admin/compactDisc-list.xhtml".
You are free to change the algorithm if you want. Define your own class that
implements ViewControllerMapper, and then configure it by specifying the fully
qualified class name as the value of a context init parameter named
"org.apache.shale.view.VIEW_CONTROLLER_MAPPER" in your web.xml file.
> By the way, I'm using MyFaces, Facelets, Shale and Spring together
> and I noticed some issues with Shale Tiger and Spring:
Since these are really separate issues, they should really be filed separately
:-).
> - Shale only supports "request"-scoped beans for ViewControllers. My
> listController is in session-scope because I want settings like sort order,
> list cursor and filter settings to be persistent across multiple invocations
> (especially useful for a list-detail scenario where the user is returned to
> the right page of list data after completing the detail form).
Supporting only request scope view controllers is a deliberate design decision.
You are mixing controller and view information in your scenario above ... I
would handle that by storing the cursor and filter settings in a separate
data-only bean in session scope, and referencing it from your request scoped
controller.
> - I cannot override defaults in the faces-config.xml contained in
> shale-view.jar
> with Spring. This is because the Spring VariableResolver first asks the
> underlying
> (Shale/JSF) resolver. I'm afraid I cannot write
<!-- Shale View-Controller-Mapping -->
<bean name="org$apache$shale$view$VIEW_MAPPER"
class="teuto.base.shale.MemoryViewControllerMapper">
<property name="mappings">
<props>
<prop
key="/admin/compactDisc-list.xhtml">compactDiscListController</prop>
</props>
</property>
</bean>
but I need to declare the following in my faces-config.xml
<managed-bean>
<managed-bean-name>org$apache$shale$view$VIEW_MAPPER</managed-bean-name>
<managed-bean-class>teuto.base.shale.MemoryViewControllerMapper</managed-bean-class>
<managed-bean-scope>application</managed-bean-scope>
</managed-bean>
> The same goes for "org$apache$shale$view$VIEW_CALLBACKS" (which I need
> to set to org.apache.shale.tiger.view.faces.ViewControllerCallbacks2 in order
> to make Shale Tiger work, which should not be necessary, but might also be
> because of a Spring problem - don't know).
There are a couple of related problems here.
* JSF provides no mechanism for controlling the order in which
the variable resolver chain (or any other configurable plugin chain)
gets initialized. Therefore, there's no way to insist that the
Spring variable resolver chain gets invoked first.
* You can configure the replacement view controller mapper, if
you want, by a context init parameter. See above for info.
* For any Shale feature that is implemented as a default managed bean
(such as the callbacks controller), the most reliable way to initialize
your own version is to set up a ServletContextListener. In the
contextInitialized method, use Spring's bean factory (via the
application context) to create and configure the instance you want
to use, and then store it in application scope under the appropriate
key (if you're using Spring 2.0 or later, you can ask Spring to do this
latter part for you).
> These limitations made me not use Shale View (which I very much would
> like to use), but instead implement an own mechanism for delegating
> PhaseListener events to controller beans. I'm not sure whether you are
> interested, but if you like I would share the code with you. :-)
Do the above suggestions deal with your concerns?
> 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.
