[shale] ViewController configuration

[Sean Schofield <se...@gmail.com>]

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?

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?

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?

sean

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

Re: [shale] ViewController configuration

[Craig McClanahan <cr...@gmail.com>]

On Mon, 17 Jan 2005 19:06:26 -0500, Sean Schofield
<se...@gmail.com> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org