You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Sean Schofield <se...@gmail.com> on 2005/07/06 20:18:58 UTC
Fwd: [shale] Configuring TilesViewHandler
Sorry, accidentaly sent to the myfaces dev list (instead of struts-dev.)
sean
---------- Forwarded message ----------
From: Sean Schofield <se...@gmail.com>
Date: Jul 6, 2005 2:18 PM
Subject: [shale] Configuring TilesViewHandler
To: MyFaces Development <de...@myfaces.apache.org>
First off. Thanks to David for committing his Tiles stuf. We've been
waiting for that for a while now ;-)
I'm wondering how I can configure Shale and Tiles to work together. I
know there will probably be examples, blogs, etc. forthcoming but a
quick hint might help me get jumpstarted. Its actually a general JSF
question.
How can you configure *multiple* view controllers for a JSF
application? I know you can use
<application>
<view-handler> org.apache.shale.faces.ShaleViewHandler</view-handler>
</application>
This is the feature in JSF that allows you to decorate the default
ViewController. But how do you use the ShaleViewHandler and
TilesViewHandler together? Can you specify multiple <viewhandler>
elements or is there some other trick?
TIA,
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Configuring TilesViewHandler
Posted by David Geary <sa...@earthlink.net>.
Le 05-07-07 à 11:44, Craig McClanahan a écrit :
> On 7/7/05, David Geary <sa...@earthlink.net> wrote:
>
>> Le 05-07-06 à 21:38, Andy Freeman a écrit :
>>
>>> Again, will the Shale Tiles integration make it this easy to layout
>>> pages? I am sure there is a bit of web.xml configuration to do
>>> and I
>>> am okay with that, but looking at the sample ASP.NET code, I hope it
>>> is not a lot. I think this is simply too powerful of a concept
>>> to not
>>> have an equivalent on the Java side.
>>>
>>
>> There's no web.xml configuration if you use Shale's Tiles
>> integration. shale-tiles.jar
>> contains a META-INF/web.xml file that declares the Tiles servlet.
>>
>>
>
> Oh how I wish that (META-INF/web.xml) actually worked, but it doesn't
> actually :-).
>
> The shale-tiles jar does have a META-INF/faces-config.xml file in it,
> to declare the custom ViewHandler implementation (so there's nothing
> extra to do from the JSF viewpoint), but you do indeed have to
> configure the TilesServlet in your application's web.xml
Oops, I misspoke. You do have to declare the Tiles servlet.
> as well as
> tell it the definition files to use.
If you use the default definition file for standalone Tiles (/WEB-INF/
tiles.xml),
you can skip that step.
david
>
> 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
Re: [shale] Configuring TilesViewHandler
Posted by Craig McClanahan <cr...@gmail.com>.
On 7/7/05, David Geary <sa...@earthlink.net> wrote:
> Le 05-07-06 à 21:38, Andy Freeman a écrit :
> > Again, will the Shale Tiles integration make it this easy to layout
> > pages? I am sure there is a bit of web.xml configuration to do and I
> > am okay with that, but looking at the sample ASP.NET code, I hope it
> > is not a lot. I think this is simply too powerful of a concept to not
> > have an equivalent on the Java side.
>
> There's no web.xml configuration if you use Shale's Tiles
> integration. shale-tiles.jar
> contains a META-INF/web.xml file that declares the Tiles servlet.
>
Oh how I wish that (META-INF/web.xml) actually worked, but it doesn't
actually :-).
The shale-tiles jar does have a META-INF/faces-config.xml file in it,
to declare the custom ViewHandler implementation (so there's nothing
extra to do from the JSF viewpoint), but you do indeed have to
configure the TilesServlet in your application's web.xml, as well as
tell it the definition files to use.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Configuring TilesViewHandler
Posted by David Geary <sa...@earthlink.net>.
Le 05-07-06 à 21:38, Andy Freeman a écrit :
> On 7/6/05, David Geary <sa...@earthlink.net> wrote:
>
>>
>> Le 05-07-06 à 15:50, Andy Freeman a écrit :
>>
>>
>>> Craig,
>>> How do you think that the Shale-JSF-Tiles implementation compares
>>> to what
>>> MS is introducing with ASP.NET <http://ASP.NET> 2.0's Master Pages?
>>> article:
>>> http://www.ondotnet.com/pub/a/dotnet/2004/09/27/
>>> libertyonwhidbey.html
>>> sample source code:
>>> http://www.ondotnet.com/dotnet/2004/09/27/examples/Source.zip
>>> thanks,
>>> Andy
>>>
>>
>> Tiles is very much like ASP 2.0 Master Pages. They both compose
>> disparate content fragments into a page and you can specify that
>> content statically with XML or dynamically, with code.
>>
>> Shale's Tiles integration lets you load a tile directly instead of
>> loading a JSP page that inserts the tile. You can also specify a JSP
>> page or a tile with the same view ID, which makes it easy to plug in
>> a tile for an existing page, or vice-versa.
>>
>
> David,
>
> I have use Struts and Tiles together in the past. I always found
> Tiles to somewhat verbose if you used the XML structure. :(
>
> With the Shales Tiles integration, will it be this simple to create
> pages?
>
>
> First, create a master page to define the overall page layout:
>
> TopMasterPage.master
> -----------------------------------------
> <%@ Master Language="C#" CompileWith="TopMasterPage.master.cs"
> ClassName="TopMasterPage_master" %>
> ...
> <body>
> ...
> <div>
> <asp:contentplaceholder id="TopPageContent" runat="server">If you see
> this content,
> then the master page content was not
> replaced<br />
> </asp:contentplaceholder>
> </div>
> ...
> -----------------------------------------
>
>
> Second, create a content page which defines which master page to use,
> which content id(s) to insert the content into, and what the page
> title is:
>
> Welcome.aspx
> -----------------------------------------
> <%@ Page Language="C#" MasterPageFile="~/TopMasterPage.master"
> CompileWith="Welcome.aspx.cs" ClassName="Welcome_aspx" Title="Welcome
> Page" %>
> <%@ MasterType VirtualPath="~/TopMasterPage.master" %>
>
> <asp:Content ID="Content1" ContentPlaceHolderID="TopPageContent"
> Runat="server">
> This is
> the content of the welcome page.
> ...
> </asp:Content>
> ------------------------------------------
>
> Third, there is no third. Since MS made Master Pages a first class
> concept within ASP.NET 2.0 you don't need to modify the Web.Config
> file and you don't need to create something like a tiles-defs.xml file
> in order to take advantage of them. Here is the sample code link I
> sent earlier: http://www.ondotnet.com/dotnet/2004/09/27/examples/
> Source.zip
>
> Again, will the Shale Tiles integration make it this easy to layout
> pages? I am sure there is a bit of web.xml configuration to do and I
> am okay with that, but looking at the sample ASP.NET code, I hope it
> is not a lot. I think this is simply too powerful of a concept to not
> have an equivalent on the Java side.
There's no web.xml configuration if you use Shale's Tiles
integration. shale-tiles.jar
contains a META-INF/web.xml file that declares the Tiles servlet.
You do have an XML config file, though. I'm not convinced that
ASP.NET is
easier. You still have to specify the same information: which page is
the layout,
(master) which represent content, and how they are contained. With
Tiles, you specify
that information in an XML file, with ASP.NET, you inline it in ASP
(apparently from the
preceeding example--sorry I haven't used ASP.NET).
I know Tiles gets dinged for its config file now that everyone
suddenly hates XML.
But IMO, it's one of Tiles strengths. I can see how all my pages are
composed and
do amazing things with tiles in the context of a single XML file.
david
>
> thanks,
> Andy
>
> ---------------------------------------------------------------------
> 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
Re: [shale] Configuring TilesViewHandler
Posted by Andy Freeman <an...@gmail.com>.
On 7/6/05, David Geary <sa...@earthlink.net> wrote:
>
> Le 05-07-06 à 15:50, Andy Freeman a écrit :
>
> > Craig,
> > How do you think that the Shale-JSF-Tiles implementation compares
> > to what
> > MS is introducing with ASP.NET <http://ASP.NET> 2.0's Master Pages?
> > article:
> > http://www.ondotnet.com/pub/a/dotnet/2004/09/27/libertyonwhidbey.html
> > sample source code:
> > http://www.ondotnet.com/dotnet/2004/09/27/examples/Source.zip
> > thanks,
> > Andy
>
> Tiles is very much like ASP 2.0 Master Pages. They both compose
> disparate content fragments into a page and you can specify that
> content statically with XML or dynamically, with code.
>
> Shale's Tiles integration lets you load a tile directly instead of
> loading a JSP page that inserts the tile. You can also specify a JSP
> page or a tile with the same view ID, which makes it easy to plug in
> a tile for an existing page, or vice-versa.
David,
I have use Struts and Tiles together in the past. I always found
Tiles to somewhat verbose if you used the XML structure. :(
With the Shales Tiles integration, will it be this simple to create pages?
First, create a master page to define the overall page layout:
TopMasterPage.master
-----------------------------------------
<%@ Master Language="C#" CompileWith="TopMasterPage.master.cs"
ClassName="TopMasterPage_master" %>
...
<body>
...
<div>
<asp:contentplaceholder id="TopPageContent" runat="server">If you see
this content,
then the master page content was not replaced<br />
</asp:contentplaceholder>
</div>
...
-----------------------------------------
Second, create a content page which defines which master page to use,
which content id(s) to insert the content into, and what the page
title is:
Welcome.aspx
-----------------------------------------
<%@ Page Language="C#" MasterPageFile="~/TopMasterPage.master"
CompileWith="Welcome.aspx.cs" ClassName="Welcome_aspx" Title="Welcome
Page" %>
<%@ MasterType VirtualPath="~/TopMasterPage.master" %>
<asp:Content ID="Content1" ContentPlaceHolderID="TopPageContent" Runat="server">
This is
the content of the welcome page.
...
</asp:Content>
------------------------------------------
Third, there is no third. Since MS made Master Pages a first class
concept within ASP.NET 2.0 you don't need to modify the Web.Config
file and you don't need to create something like a tiles-defs.xml file
in order to take advantage of them. Here is the sample code link I
sent earlier: http://www.ondotnet.com/dotnet/2004/09/27/examples/Source.zip
Again, will the Shale Tiles integration make it this easy to layout
pages? I am sure there is a bit of web.xml configuration to do and I
am okay with that, but looking at the sample ASP.NET code, I hope it
is not a lot. I think this is simply too powerful of a concept to not
have an equivalent on the Java side.
thanks,
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Configuring TilesViewHandler
Posted by David Geary <sa...@earthlink.net>.
Le 05-07-06 à 15:50, Andy Freeman a écrit :
> Craig,
> How do you think that the Shale-JSF-Tiles implementation compares
> to what
> MS is introducing with ASP.NET <http://ASP.NET> 2.0's Master Pages?
> article:
> http://www.ondotnet.com/pub/a/dotnet/2004/09/27/libertyonwhidbey.html
> sample source code:
> http://www.ondotnet.com/dotnet/2004/09/27/examples/Source.zip
> thanks,
> Andy
Tiles is very much like ASP 2.0 Master Pages. They both compose
disparate content fragments into a page and you can specify that
content statically with XML or dynamically, with code.
Shale's Tiles integration lets you load a tile directly instead of
loading a JSP page that inserts the tile. You can also specify a JSP
page or a tile with the same view ID, which makes it easy to plug in
a tile for an existing page, or vice-versa.
david
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Configuring TilesViewHandler
Posted by Andy Freeman <an...@gmail.com>.
Craig,
How do you think that the Shale-JSF-Tiles implementation compares to what
MS is introducing with ASP.NET <http://ASP.NET> 2.0's Master Pages?
article:
http://www.ondotnet.com/pub/a/dotnet/2004/09/27/libertyonwhidbey.html
sample source code:
http://www.ondotnet.com/dotnet/2004/09/27/examples/Source.zip
thanks,
Andy
Re: [shale] Configuring TilesViewHandler
Posted by Martin Marinschek <ma...@gmail.com>.
Just to clarify: that has also been as such _before_ Thomas has looked
at it, so for several months this must have been working.
Blame marketing ;) !
regards,
Martin
On 7/8/05, Thomas Spiegl <th...@gmail.com> wrote:
> I took a look at the JspTilesViewHandler. It just has dependencies on shared
> classes.
> So the view handler is independend from the myfaces-implementation by now.
> From there it should also run on any otherJSF implementation.
>
>
> On 7/7/05, Sean Schofield <sean.schofield@gmail.com > wrote:
> > I am definitely *not* looking at this right now (too much other
> > stuff.) Also you are the expert :-)
> >
> > sean
> >
> > On 7/7/05, Thomas Spiegl <th...@gmail.com> wrote:
> > > hi all,
> > >
> > > yes there are dependencies in JspTilesViewHandler that should get
> > > eliminated. When i implemented TilesViewHandler i thought about moving
> all
> > > needed resources to our shared library.
> > > Sean, are you already working on this? If not, i could take a look at
> > > MyFaces JspTilesViewHandler, fix the dependencies.
> > >
> > > regards, thomas
> > >
> > >
> > > On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> > > > Yes but the JspTilesViewHandler requires MyFaces implementation (for
> > > > now.) Something I discovered very early on when playing with MyFaces.
> > > > This is fixable but I can see why someone wanted to write one that
> > > > worked with the RI.
> > > >
> > > > I was always under the impression that you could only use one
> > > > user-supplied ViewHandler. That was why I was so keen on seeing
> > > > David's added to Shale (which also has a view Handler.) I didn't
> > > > realize he was going to write one that stands alone. That said, its a
> > > > nice job.
> > > >
> > > > As the two projects mature we should revisit the idea of joining
> > > > forces when it comes to pure JSF components that don't require Shale
> > > > or MyFaces implementation.
> > > >
> > > > sean
> > > >
> > > >
> > > > On 7/7/05, Manfred Geiler < manfred.geiler@gmail.com> wrote:
> > > > > And all those things (delegation, chain to default view handler) are
> > > > > already implemented in the JspTilesViewHandler that Thomas has
> written
> > > > > months ago.
> > > > >
> > > > > *sigh*
> > > > > We need better marketing... ;-)
> > > > >
> > > > > -Manfred
> > > > >
> > > > >
> > > > > 2005/7/7, Sean Schofield <sean.schofield@gmail.com >:
> > > > > > > Actually, extending is *not* the recommended way to do this,
> because
> > > > > > > it ties the implementations too tightly together.
> > > > > >
> > > > > > I agreed this is to be avoided but I wasn't aware that its
> possible to
> > > > > > chain the ViewHandlers.
> > > > > >
> > > > > > [snip]
> > > > > >
> > > > > > > The key is that each implementation of ViewHandler should have a
> > > > > > > constructor that takes a ViewHandler argument. As the JSF
> runtime
> > > is
> > > > > > > processing configuration files, it should be checking whether
> such a
> > > > > > > constructor exists. If it does, the runtime will call *that*
> > > > > > > constructor (passing in the most recent "default"
> implementation) so
> > > > > > > that you can construct a *chain* of implementations that can add
> > > > > > > specialized behavior where relevant, or delegate to the previous
> > > > > > > implementation for all the regular use cases.
> > > > > >
> > > > > > That changes things then. I was reading up on ViewHandler but
> > > > > > everything I read kept mentioning that the "default"
> implementation
> > > > > > would be passed. It wasn't clear that the meaning of "default"
> was
> > > > > > really "default as decorated so far."
> > > > > >
> > > > > > A chain was what I was going to suggest for a spec revision but it
> > > > > > appears that this has already been anticipated ;-)
> > > > > >
> > > > > > > Separating the two implementations allows a Shale user who is
> *not*
> > > > > > > using Tiles from having to pay any overhead at all for the fact
> that
> > > > > > > shales-tiles.jar is available (although, not in this webapp,
> > > > > > > obviously). It also means that shale-tiles.jar (the interface
> > > layer)
> > > > > > > will have *zero* dependencies on Shale -- at least, once I clean
> up
> > > > > > > the localization thing -- so it can be used (with MyFaces or any
> > > other
> > > > > > > JSF implementation) without the rest of Shale.
> > > > > >
> > > > > > I agree that you would want the ability to use TilesViewHandler
> > > > > > without the rest of Shale, that's why I figured ShaleViewHandler
> would
> > > > > > extend TilesViewHandler instead of the other way around. Turns
> out
> > > > > > extension is not needed.
> > > > > >
> > > > > > An interesting aspect of the decorator/chain pattern is that you
> need
> > > > > > to know a little bit about the internals of the ViewHandlers that
> your
> > > > > > are chaining together. Its possible that there could be a
> conflict
> > > > > > between two ViewHandlers that want to do two different things in
> the
> > > > > > same interface method. Also, I can envision situations where the
> > > > > > order of decoration might be important (not this case though.)
> > > > > >
> > > > > > [snip]
> > > > > >
> > > > > > Thanks for the clarifying this.
> > > > > >
> > > > > > sean
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
Re: [shale] Configuring TilesViewHandler
Posted by Thomas Spiegl <th...@gmail.com>.
I took a look at the JspTilesViewHandler. It just has dependencies on shared
classes.
So the view handler is independend from the myfaces-implementation by now.
>From there it should also run on any otherJSF implementation.
On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
>
> I am definitely *not* looking at this right now (too much other
> stuff.) Also you are the expert :-)
>
> sean
>
> On 7/7/05, Thomas Spiegl <th...@gmail.com> wrote:
> > hi all,
> >
> > yes there are dependencies in JspTilesViewHandler that should get
> > eliminated. When i implemented TilesViewHandler i thought about moving
> all
> > needed resources to our shared library.
> > Sean, are you already working on this? If not, i could take a look at
> > MyFaces JspTilesViewHandler, fix the dependencies.
> >
> > regards, thomas
> >
> >
> > On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> > > Yes but the JspTilesViewHandler requires MyFaces implementation (for
> > > now.) Something I discovered very early on when playing with MyFaces.
> > > This is fixable but I can see why someone wanted to write one that
> > > worked with the RI.
> > >
> > > I was always under the impression that you could only use one
> > > user-supplied ViewHandler. That was why I was so keen on seeing
> > > David's added to Shale (which also has a view Handler.) I didn't
> > > realize he was going to write one that stands alone. That said, its a
> > > nice job.
> > >
> > > As the two projects mature we should revisit the idea of joining
> > > forces when it comes to pure JSF components that don't require Shale
> > > or MyFaces implementation.
> > >
> > > sean
> > >
> > >
> > > On 7/7/05, Manfred Geiler < manfred.geiler@gmail.com> wrote:
> > > > And all those things (delegation, chain to default view handler) are
> > > > already implemented in the JspTilesViewHandler that Thomas has
> written
> > > > months ago.
> > > >
> > > > *sigh*
> > > > We need better marketing... ;-)
> > > >
> > > > -Manfred
> > > >
> > > >
> > > > 2005/7/7, Sean Schofield <sean.schofield@gmail.com >:
> > > > > > Actually, extending is *not* the recommended way to do this,
> because
> > > > > > it ties the implementations too tightly together.
> > > > >
> > > > > I agreed this is to be avoided but I wasn't aware that its
> possible to
> > > > > chain the ViewHandlers.
> > > > >
> > > > > [snip]
> > > > >
> > > > > > The key is that each implementation of ViewHandler should have a
> > > > > > constructor that takes a ViewHandler argument. As the JSF
> runtime
> > is
> > > > > > processing configuration files, it should be checking whether
> such a
> > > > > > constructor exists. If it does, the runtime will call *that*
> > > > > > constructor (passing in the most recent "default"
> implementation) so
> > > > > > that you can construct a *chain* of implementations that can add
> > > > > > specialized behavior where relevant, or delegate to the previous
> > > > > > implementation for all the regular use cases.
> > > > >
> > > > > That changes things then. I was reading up on ViewHandler but
> > > > > everything I read kept mentioning that the "default"
> implementation
> > > > > would be passed. It wasn't clear that the meaning of "default" was
> > > > > really "default as decorated so far."
> > > > >
> > > > > A chain was what I was going to suggest for a spec revision but it
> > > > > appears that this has already been anticipated ;-)
> > > > >
> > > > > > Separating the two implementations allows a Shale user who is
> *not*
> > > > > > using Tiles from having to pay any overhead at all for the fact
> that
> > > > > > shales-tiles.jar is available (although, not in this webapp,
> > > > > > obviously). It also means that shale-tiles.jar (the interface
> > layer)
> > > > > > will have *zero* dependencies on Shale -- at least, once I clean
> up
> > > > > > the localization thing -- so it can be used (with MyFaces or any
> > other
> > > > > > JSF implementation) without the rest of Shale.
> > > > >
> > > > > I agree that you would want the ability to use TilesViewHandler
> > > > > without the rest of Shale, that's why I figured ShaleViewHandler
> would
> > > > > extend TilesViewHandler instead of the other way around. Turns out
> > > > > extension is not needed.
> > > > >
> > > > > An interesting aspect of the decorator/chain pattern is that you
> need
> > > > > to know a little bit about the internals of the ViewHandlers that
> your
> > > > > are chaining together. Its possible that there could be a conflict
> > > > > between two ViewHandlers that want to do two different things in
> the
> > > > > same interface method. Also, I can envision situations where the
> > > > > order of decoration might be important (not this case though.)
> > > > >
> > > > > [snip]
> > > > >
> > > > > Thanks for the clarifying this.
> > > > >
> > > > > sean
> > > > >
> > > >
> > >
> >
> >
>
Re: [shale] Configuring TilesViewHandler
Posted by Sean Schofield <se...@gmail.com>.
I am definitely *not* looking at this right now (too much other
stuff.) Also you are the expert :-)
sean
On 7/7/05, Thomas Spiegl <th...@gmail.com> wrote:
> hi all,
>
> yes there are dependencies in JspTilesViewHandler that should get
> eliminated. When i implemented TilesViewHandler i thought about moving all
> needed resources to our shared library.
> Sean, are you already working on this? If not, i could take a look at
> MyFaces JspTilesViewHandler, fix the dependencies.
>
> regards, thomas
>
>
> On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
> > Yes but the JspTilesViewHandler requires MyFaces implementation (for
> > now.) Something I discovered very early on when playing with MyFaces.
> > This is fixable but I can see why someone wanted to write one that
> > worked with the RI.
> >
> > I was always under the impression that you could only use one
> > user-supplied ViewHandler. That was why I was so keen on seeing
> > David's added to Shale (which also has a view Handler.) I didn't
> > realize he was going to write one that stands alone. That said, its a
> > nice job.
> >
> > As the two projects mature we should revisit the idea of joining
> > forces when it comes to pure JSF components that don't require Shale
> > or MyFaces implementation.
> >
> > sean
> >
> >
> > On 7/7/05, Manfred Geiler < manfred.geiler@gmail.com> wrote:
> > > And all those things (delegation, chain to default view handler) are
> > > already implemented in the JspTilesViewHandler that Thomas has written
> > > months ago.
> > >
> > > *sigh*
> > > We need better marketing... ;-)
> > >
> > > -Manfred
> > >
> > >
> > > 2005/7/7, Sean Schofield <sean.schofield@gmail.com >:
> > > > > Actually, extending is *not* the recommended way to do this, because
> > > > > it ties the implementations too tightly together.
> > > >
> > > > I agreed this is to be avoided but I wasn't aware that its possible to
> > > > chain the ViewHandlers.
> > > >
> > > > [snip]
> > > >
> > > > > The key is that each implementation of ViewHandler should have a
> > > > > constructor that takes a ViewHandler argument. As the JSF runtime
> is
> > > > > processing configuration files, it should be checking whether such a
> > > > > constructor exists. If it does, the runtime will call *that*
> > > > > constructor (passing in the most recent "default" implementation) so
> > > > > that you can construct a *chain* of implementations that can add
> > > > > specialized behavior where relevant, or delegate to the previous
> > > > > implementation for all the regular use cases.
> > > >
> > > > That changes things then. I was reading up on ViewHandler but
> > > > everything I read kept mentioning that the "default" implementation
> > > > would be passed. It wasn't clear that the meaning of "default" was
> > > > really "default as decorated so far."
> > > >
> > > > A chain was what I was going to suggest for a spec revision but it
> > > > appears that this has already been anticipated ;-)
> > > >
> > > > > Separating the two implementations allows a Shale user who is *not*
> > > > > using Tiles from having to pay any overhead at all for the fact that
> > > > > shales-tiles.jar is available (although, not in this webapp,
> > > > > obviously). It also means that shale-tiles.jar (the interface
> layer)
> > > > > will have *zero* dependencies on Shale -- at least, once I clean up
> > > > > the localization thing -- so it can be used (with MyFaces or any
> other
> > > > > JSF implementation) without the rest of Shale.
> > > >
> > > > I agree that you would want the ability to use TilesViewHandler
> > > > without the rest of Shale, that's why I figured ShaleViewHandler would
> > > > extend TilesViewHandler instead of the other way around. Turns out
> > > > extension is not needed.
> > > >
> > > > An interesting aspect of the decorator/chain pattern is that you need
> > > > to know a little bit about the internals of the ViewHandlers that your
> > > > are chaining together. Its possible that there could be a conflict
> > > > between two ViewHandlers that want to do two different things in the
> > > > same interface method. Also, I can envision situations where the
> > > > order of decoration might be important (not this case though.)
> > > >
> > > > [snip]
> > > >
> > > > Thanks for the clarifying this.
> > > >
> > > > sean
> > > >
> > >
> >
>
>
Re: [shale] Configuring TilesViewHandler
Posted by Thomas Spiegl <th...@gmail.com>.
hi all,
yes there are dependencies in JspTilesViewHandler that should get
eliminated. When i implemented TilesViewHandler i thought about moving all
needed resources to our shared library.
Sean, are you already working on this? If not, i could take a look at
MyFaces JspTilesViewHandler, fix the dependencies.
regards, thomas
On 7/7/05, Sean Schofield <se...@gmail.com> wrote:
>
> Yes but the JspTilesViewHandler requires MyFaces implementation (for
> now.) Something I discovered very early on when playing with MyFaces.
> This is fixable but I can see why someone wanted to write one that
> worked with the RI.
>
> I was always under the impression that you could only use one
> user-supplied ViewHandler. That was why I was so keen on seeing
> David's added to Shale (which also has a view Handler.) I didn't
> realize he was going to write one that stands alone. That said, its a
> nice job.
>
> As the two projects mature we should revisit the idea of joining
> forces when it comes to pure JSF components that don't require Shale
> or MyFaces implementation.
>
> sean
>
>
> On 7/7/05, Manfred Geiler <ma...@gmail.com> wrote:
> > And all those things (delegation, chain to default view handler) are
> > already implemented in the JspTilesViewHandler that Thomas has written
> > months ago.
> >
> > *sigh*
> > We need better marketing... ;-)
> >
> > -Manfred
> >
> >
> > 2005/7/7, Sean Schofield <se...@gmail.com>:
> > > > Actually, extending is *not* the recommended way to do this, because
> > > > it ties the implementations too tightly together.
> > >
> > > I agreed this is to be avoided but I wasn't aware that its possible to
> > > chain the ViewHandlers.
> > >
> > > [snip]
> > >
> > > > The key is that each implementation of ViewHandler should have a
> > > > constructor that takes a ViewHandler argument. As the JSF runtime is
> > > > processing configuration files, it should be checking whether such a
> > > > constructor exists. If it does, the runtime will call *that*
> > > > constructor (passing in the most recent "default" implementation) so
> > > > that you can construct a *chain* of implementations that can add
> > > > specialized behavior where relevant, or delegate to the previous
> > > > implementation for all the regular use cases.
> > >
> > > That changes things then. I was reading up on ViewHandler but
> > > everything I read kept mentioning that the "default" implementation
> > > would be passed. It wasn't clear that the meaning of "default" was
> > > really "default as decorated so far."
> > >
> > > A chain was what I was going to suggest for a spec revision but it
> > > appears that this has already been anticipated ;-)
> > >
> > > > Separating the two implementations allows a Shale user who is *not*
> > > > using Tiles from having to pay any overhead at all for the fact that
> > > > shales-tiles.jar is available (although, not in this webapp,
> > > > obviously). It also means that shale-tiles.jar (the interface layer)
> > > > will have *zero* dependencies on Shale -- at least, once I clean up
> > > > the localization thing -- so it can be used (with MyFaces or any
> other
> > > > JSF implementation) without the rest of Shale.
> > >
> > > I agree that you would want the ability to use TilesViewHandler
> > > without the rest of Shale, that's why I figured ShaleViewHandler would
> > > extend TilesViewHandler instead of the other way around. Turns out
> > > extension is not needed.
> > >
> > > An interesting aspect of the decorator/chain pattern is that you need
> > > to know a little bit about the internals of the ViewHandlers that your
> > > are chaining together. Its possible that there could be a conflict
> > > between two ViewHandlers that want to do two different things in the
> > > same interface method. Also, I can envision situations where the
> > > order of decoration might be important (not this case though.)
> > >
> > > [snip]
> > >
> > > Thanks for the clarifying this.
> > >
> > > sean
> > >
> >
>
Re: [shale] Configuring TilesViewHandler
Posted by Sean Schofield <se...@gmail.com>.
Yes but the JspTilesViewHandler requires MyFaces implementation (for
now.) Something I discovered very early on when playing with MyFaces.
This is fixable but I can see why someone wanted to write one that
worked with the RI.
I was always under the impression that you could only use one
user-supplied ViewHandler. That was why I was so keen on seeing
David's added to Shale (which also has a view Handler.) I didn't
realize he was going to write one that stands alone. That said, its a
nice job.
As the two projects mature we should revisit the idea of joining
forces when it comes to pure JSF components that don't require Shale
or MyFaces implementation.
sean
On 7/7/05, Manfred Geiler <ma...@gmail.com> wrote:
> And all those things (delegation, chain to default view handler) are
> already implemented in the JspTilesViewHandler that Thomas has written
> months ago.
>
> *sigh*
> We need better marketing... ;-)
>
> -Manfred
>
>
> 2005/7/7, Sean Schofield <se...@gmail.com>:
> > > Actually, extending is *not* the recommended way to do this, because
> > > it ties the implementations too tightly together.
> >
> > I agreed this is to be avoided but I wasn't aware that its possible to
> > chain the ViewHandlers.
> >
> > [snip]
> >
> > > The key is that each implementation of ViewHandler should have a
> > > constructor that takes a ViewHandler argument. As the JSF runtime is
> > > processing configuration files, it should be checking whether such a
> > > constructor exists. If it does, the runtime will call *that*
> > > constructor (passing in the most recent "default" implementation) so
> > > that you can construct a *chain* of implementations that can add
> > > specialized behavior where relevant, or delegate to the previous
> > > implementation for all the regular use cases.
> >
> > That changes things then. I was reading up on ViewHandler but
> > everything I read kept mentioning that the "default" implementation
> > would be passed. It wasn't clear that the meaning of "default" was
> > really "default as decorated so far."
> >
> > A chain was what I was going to suggest for a spec revision but it
> > appears that this has already been anticipated ;-)
> >
> > > Separating the two implementations allows a Shale user who is *not*
> > > using Tiles from having to pay any overhead at all for the fact that
> > > shales-tiles.jar is available (although, not in this webapp,
> > > obviously). It also means that shale-tiles.jar (the interface layer)
> > > will have *zero* dependencies on Shale -- at least, once I clean up
> > > the localization thing -- so it can be used (with MyFaces or any other
> > > JSF implementation) without the rest of Shale.
> >
> > I agree that you would want the ability to use TilesViewHandler
> > without the rest of Shale, that's why I figured ShaleViewHandler would
> > extend TilesViewHandler instead of the other way around. Turns out
> > extension is not needed.
> >
> > An interesting aspect of the decorator/chain pattern is that you need
> > to know a little bit about the internals of the ViewHandlers that your
> > are chaining together. Its possible that there could be a conflict
> > between two ViewHandlers that want to do two different things in the
> > same interface method. Also, I can envision situations where the
> > order of decoration might be important (not this case though.)
> >
> > [snip]
> >
> > Thanks for the clarifying this.
> >
> > sean
> >
>
Re: [shale] Configuring TilesViewHandler
Posted by Manfred Geiler <ma...@gmail.com>.
And all those things (delegation, chain to default view handler) are
already implemented in the JspTilesViewHandler that Thomas has written
months ago.
*sigh*
We need better marketing... ;-)
-Manfred
2005/7/7, Sean Schofield <se...@gmail.com>:
> > Actually, extending is *not* the recommended way to do this, because
> > it ties the implementations too tightly together.
>
> I agreed this is to be avoided but I wasn't aware that its possible to
> chain the ViewHandlers.
>
> [snip]
>
> > The key is that each implementation of ViewHandler should have a
> > constructor that takes a ViewHandler argument. As the JSF runtime is
> > processing configuration files, it should be checking whether such a
> > constructor exists. If it does, the runtime will call *that*
> > constructor (passing in the most recent "default" implementation) so
> > that you can construct a *chain* of implementations that can add
> > specialized behavior where relevant, or delegate to the previous
> > implementation for all the regular use cases.
>
> That changes things then. I was reading up on ViewHandler but
> everything I read kept mentioning that the "default" implementation
> would be passed. It wasn't clear that the meaning of "default" was
> really "default as decorated so far."
>
> A chain was what I was going to suggest for a spec revision but it
> appears that this has already been anticipated ;-)
>
> > Separating the two implementations allows a Shale user who is *not*
> > using Tiles from having to pay any overhead at all for the fact that
> > shales-tiles.jar is available (although, not in this webapp,
> > obviously). It also means that shale-tiles.jar (the interface layer)
> > will have *zero* dependencies on Shale -- at least, once I clean up
> > the localization thing -- so it can be used (with MyFaces or any other
> > JSF implementation) without the rest of Shale.
>
> I agree that you would want the ability to use TilesViewHandler
> without the rest of Shale, that's why I figured ShaleViewHandler would
> extend TilesViewHandler instead of the other way around. Turns out
> extension is not needed.
>
> An interesting aspect of the decorator/chain pattern is that you need
> to know a little bit about the internals of the ViewHandlers that your
> are chaining together. Its possible that there could be a conflict
> between two ViewHandlers that want to do two different things in the
> same interface method. Also, I can envision situations where the
> order of decoration might be important (not this case though.)
>
> [snip]
>
> Thanks for the clarifying this.
>
> sean
>
Re: [shale] Configuring TilesViewHandler
Posted by Sean Schofield <se...@gmail.com>.
> Actually, extending is *not* the recommended way to do this, because
> it ties the implementations too tightly together.
I agreed this is to be avoided but I wasn't aware that its possible to
chain the ViewHandlers.
[snip]
> The key is that each implementation of ViewHandler should have a
> constructor that takes a ViewHandler argument. As the JSF runtime is
> processing configuration files, it should be checking whether such a
> constructor exists. If it does, the runtime will call *that*
> constructor (passing in the most recent "default" implementation) so
> that you can construct a *chain* of implementations that can add
> specialized behavior where relevant, or delegate to the previous
> implementation for all the regular use cases.
That changes things then. I was reading up on ViewHandler but
everything I read kept mentioning that the "default" implementation
would be passed. It wasn't clear that the meaning of "default" was
really "default as decorated so far."
A chain was what I was going to suggest for a spec revision but it
appears that this has already been anticipated ;-)
> Separating the two implementations allows a Shale user who is *not*
> using Tiles from having to pay any overhead at all for the fact that
> shales-tiles.jar is available (although, not in this webapp,
> obviously). It also means that shale-tiles.jar (the interface layer)
> will have *zero* dependencies on Shale -- at least, once I clean up
> the localization thing -- so it can be used (with MyFaces or any other
> JSF implementation) without the rest of Shale.
I agree that you would want the ability to use TilesViewHandler
without the rest of Shale, that's why I figured ShaleViewHandler would
extend TilesViewHandler instead of the other way around. Turns out
extension is not needed.
An interesting aspect of the decorator/chain pattern is that you need
to know a little bit about the internals of the ViewHandlers that your
are chaining together. Its possible that there could be a conflict
between two ViewHandlers that want to do two different things in the
same interface method. Also, I can envision situations where the
order of decoration might be important (not this case though.)
[snip]
Thanks for the clarifying this.
sean
Re: [shale] Configuring TilesViewHandler
Posted by Craig McClanahan <cr...@gmail.com>.
On 7/6/05, Sean Schofield <se...@gmail.com> wrote:
> OK I got TilesViewHandler working by iteself (without
> ShaleViewHandler.) It works great. Nice work David.
>
> As for combining the two, I would recommend ShaleViewHandler extend
> TilesViewHandler. The ViewHandler interface method that
> TilesViewHandler uses is renderView. ShaleViewHandler just delegates
> the renderView method so we could just drop the method.
>
Actually, extending is *not* the recommended way to do this, because
it ties the implementations too tightly together.
> I'm curious as to how a JSF implmentation should handle multiple
> faces-config.xml files which both specify a <view-handler>. I'm
> assuming the last one processed will "win."
>
It's not just an issue of "winning", although it is true that the last
<view-handler> that is processed is the "default" one for the
application.
The key is that each implementation of ViewHandler should have a
constructor that takes a ViewHandler argument. As the JSF runtime is
processing configuration files, it should be checking whether such a
constructor exists. If it does, the runtime will call *that*
constructor (passing in the most recent "default" implementation) so
that you can construct a *chain* of implementations that can add
specialized behavior where relevant, or delegate to the previous
implementation for all the regular use cases.
Separating the two implementations allows a Shale user who is *not*
using Tiles from having to pay any overhead at all for the fact that
shales-tiles.jar is available (although, not in this webapp,
obviously). It also means that shale-tiles.jar (the interface layer)
will have *zero* dependencies on Shale -- at least, once I clean up
the localization thing -- so it can be used (with MyFaces or any other
JSF implementation) without the rest of Shale.
By the way, this same decorator pattern applies to pretty much all the
other extension points in JSF as well. In every case, you can have as
many implementations of that extensibility interface that you like,
making it easy to combine JSF-based frameworks from multiple sources
(as long as they all play by the Decorator Pattern rules). Just as an
example, that's how Shale implements dialogs -- a custom
NavigationHandler that comes into play *only* if you've purposely
entered a dialog, but just delegates to the previous implementation
(no matter where it comes from) otherwise. That way, all the standard
JSF navigation continues to work, without having to be reimplemented.
And the custom NavigationHandler does not have to depend on Shale
either -- only on JSF APIs (although in this particular case, you
would currently need to trigger the configuration yourself ... that's
pretty straightforward, though).
> sean
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Configuring TilesViewHandler
Posted by Sean Schofield <se...@gmail.com>.
OK I got TilesViewHandler working by iteself (without
ShaleViewHandler.) It works great. Nice work David.
As for combining the two, I would recommend ShaleViewHandler extend
TilesViewHandler. The ViewHandler interface method that
TilesViewHandler uses is renderView. ShaleViewHandler just delegates
the renderView method so we could just drop the method.
I'm curious as to how a JSF implmentation should handle multiple
faces-config.xml files which both specify a <view-handler>. I'm
assuming the last one processed will "win."
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org