On Mon, 17 Jan 2005 19:06:26 -0500, Sean Schofield <[EMAIL PROTECTED]> wrote: > Craig, > > In the shale-use-cases app you are configuring the managed beans with > names that include 'logon$' in them. Is the '$' a stand-in for the > '/' character?
Yes. See below for more. > > It seems like you need to know which ViewController is associated with > which page in order to supply the extra ViewController goodies. So is > the view id basically the page location (relative to the webapp) in > the JSP case? Yes, in JSF+JSP the view id is the context relative path to a particular JSP page (such as "/logon/profile1.jsp". In order to avoid having to configure the mapping between a view identifier and the corresponding ViewController explicitly, I decided to make it algorithmic -- see "org.apache.shale.ViewControllerMapper" for the mapping API, and "org.apache.shale.view.DefaultViewControllerMapper" for the default implementation, which describes how the transformation is actually done, and would return "logon$profile1" for the view identifier mentioned earlier. Note that the mapping returns the managed bean name to be instantiated ... the fully qualified class name of the ViewController class is not relevant to the mapping process. That only matters to the managed bean facility, so it is set up in faces-config.xml (along with initializing any properties you want to preset as well). > > Also, I know you said you were working on Tiles. I'm wondering how > all of this will work if your JSF page is part of a dynamic include > via Tiles. When you eventually include Tiles support will it include > all of this? A prerequisite for Tiles to work with Shale is to provide ViewController-like facilities to a resource that is included dynamically via RequestDispatcher.include() -- which is essentially what Tiles is doing under the covers. My current thinking is that each such dynamically included resource would get its own view controller (so you end up initializing multiple VCs per request), so that you could maintain the paradigm of a backing bean for each included file. My current work in progress contemplates a custom version of the <f:subview> tag, which will provide the extra services needed to call the ViewController lifecycle methods at the correct times. It's not quite working yet, but I'll check it in when it does. At that point, it should be fairly straightforward to implement Tiles support (once Tiles gets extracted out into its own subproject that is independent of Struts 1.x). > > sean > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
