You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by gv...@comcast.net on 2005/03/12 17:44:32 UTC
[Shale] subview component XML composition extension
This would be the second attempt but I would like to start a discussion on a Shale subview component extension.
Currently, The shale subview jsf component provides a post-back method to the prerender method on the ViewController. The id attribute of the component is assumed as the managed bean name. This method would be very useful for staging data for the subview and promoting reuse.
The extension would add the following features:
* Fragments of a page could be created using a XML definition and the same node structure would cover all components making it very abstract. A top-level component could be represented by a displayElement node and associated to the logical name of the JSF component using a componentType attribute.
* The describing documents could be digested at application startup and all inheritance resolved at startup. Checks for circular references would be applied.
* Like tiles, the metadata defining the subcomponent tree would support generalization inheritances and also composition inheritance. Top-level displayElement definitions can extend other top-level dislpayElements. Composition is formed using the element node that includes and overrides attributes of the target top-level node.
* It would also allow a token replacement feature of the binding EL so that the metadata describing the construction of a subcomponent tree could be reused on multiple managed bean names. Featured with the Shale life cycle methods on the ViewController, would provide many more reusable view compositions.
This composition technique could be used in conjunction with other methods too. A sample application can be downloaded from the tracking system. I removed the libraries to make the upload possible. The example uses the myfaces JSF implementation and the Shale library.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33752
Regards,
Gary VanMatre
Re: [Shale] subview component XML composition extension
Posted by Sean Schofield <se...@gmail.com>.
+1 for something like that!
On Fri, 18 Mar 2005 09:48:40 +0100, Matthias Wessendorf
<ma...@matthias-wessendorf.de> wrote:
> David-
>
> > Oops, I forgot. I do have a tiles view handler. I used the MyFaces view
> > handler as a basis for mine, but I did things a little differently.
>
> ah, fine! Have you thought about a NavigationHandler?
> I found it usefull to use tiles definitions inside struts-config.xml
> for ActionForwards.
>
> I guess it should be possible to have a NavigationHandler that
> enables you to have something like:
>
> <navigation-case>
> <from-outcome>success</from-outcome>
> <to-view-id>myTilesDefinition</to-view-id>
> </navigation-case>
>
> -Matthias
>
> > david
> >
> >>
> >> -Matthias
>
> ---------------------------------------------------------------------
> 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] subview component XML composition extension
Posted by Craig McClanahan <cr...@gmail.com>.
On Fri, 18 Mar 2005 13:06:58 -0600, Michael Rasmussen
<ra...@gmail.com> wrote:
> Craig,
> I know this came up before in a converstion we had about dialogs. I
> know it doesn't solve the problem, but I am curious, what is the
> reason behind not exposing the navigation rules publicly? I figure
> you would have some answer being on the expert group for JSF and all.
>
Mostly an issue of priorities -- we preferred to focus on the more
urgent issues. This also saved having to invent an internal
representation for the data, and then having to live with it forever.
> Michael
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Shale] subview component XML composition extension
Posted by Michael Rasmussen <ra...@gmail.com>.
Craig,
I know this came up before in a converstion we had about dialogs. I
know it doesn't solve the problem, but I am curious, what is the
reason behind not exposing the navigation rules publicly? I figure
you would have some answer being on the expert group for JSF and all.
Michael
On Fri, 18 Mar 2005 10:18:41 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> On Fri, 18 Mar 2005 09:48:40 +0100, Matthias Wessendorf
> <ma...@matthias-wessendorf.de> wrote:
> > David-
> >
> > > Oops, I forgot. I do have a tiles view handler. I used the MyFaces view
> > > handler as a basis for mine, but I did things a little differently.
> >
> > ah, fine! Have you thought about a NavigationHandler?
> > I found it usefull to use tiles definitions inside struts-config.xml
> > for ActionForwards.
> >
> > I guess it should be possible to have a NavigationHandler that
> > enables you to have something like:
> >
> > <navigation-case>
> > <from-outcome>success</from-outcome>
> > <to-view-id>myTilesDefinition</to-view-id>
> > </navigation-case>
> >
>
> That should definitely be possible ... but there's a tricky detail, in
> that there's no public JSF API to read the configured navigation
> rules. It seems likely that we'd need to define navigation rules with
> a destination of a Tile in a separate file, and have the
> NavigationHandler look there first, and delegate to the standard one
> if there is no matching rule.
>
> Craig
>
> > -Matthias
> >
> > > david
> > >
> > >>
> > >> -Matthias
> >
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Shale] subview component XML composition extension
Posted by Craig McClanahan <cr...@gmail.com>.
On Fri, 18 Mar 2005 09:48:40 +0100, Matthias Wessendorf
<ma...@matthias-wessendorf.de> wrote:
> David-
>
> > Oops, I forgot. I do have a tiles view handler. I used the MyFaces view
> > handler as a basis for mine, but I did things a little differently.
>
> ah, fine! Have you thought about a NavigationHandler?
> I found it usefull to use tiles definitions inside struts-config.xml
> for ActionForwards.
>
> I guess it should be possible to have a NavigationHandler that
> enables you to have something like:
>
> <navigation-case>
> <from-outcome>success</from-outcome>
> <to-view-id>myTilesDefinition</to-view-id>
> </navigation-case>
>
That should definitely be possible ... but there's a tricky detail, in
that there's no public JSF API to read the configured navigation
rules. It seems likely that we'd need to define navigation rules with
a destination of a Tile in a separate file, and have the
NavigationHandler look there first, and delegate to the standard one
if there is no matching rule.
Craig
> -Matthias
>
> > david
> >
> >>
> >> -Matthias
>
> ---------------------------------------------------------------------
> 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] subview component XML composition extension
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
David-
> Oops, I forgot. I do have a tiles view handler. I used the MyFaces view
> handler as a basis for mine, but I did things a little differently.
ah, fine! Have you thought about a NavigationHandler?
I found it usefull to use tiles definitions inside struts-config.xml
for ActionForwards.
I guess it should be possible to have a NavigationHandler that
enables you to have something like:
<navigation-case>
<from-outcome>success</from-outcome>
<to-view-id>myTilesDefinition</to-view-id>
</navigation-case>
-Matthias
> david
>
>>
>> -Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Shale] subview component XML composition extension
Posted by David Geary <sa...@earthlink.net>.
Le Mar 16, 2005, à 12:51 AM, Matthias Wessendorf a écrit :
> David,
>
>
>> No, I don't have anything JSF-specific. The extracted version is
>> simply decoupled from Struts. Otherwise, it's just vanilla Tiles,
>> except that I
>
> So you have no facility like a ViewHandler or something like that?
> Have you looked at MyFaces' TilesViewHandler ?
Oops, I forgot. I do have a tiles view handler. I used the MyFaces view
handler as a basis for mine, but I did things a little differently.
david
>
> -Matthias
>
> ---------------------------------------------------------------------
> 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] subview component XML composition extension
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
David,
> No, I don't have anything JSF-specific. The extracted version is simply
> decoupled from Struts. Otherwise, it's just vanilla Tiles, except that I
So you have no facility like a ViewHandler or something like that?
Have you looked at MyFaces' TilesViewHandler ?
-Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Shale] subview component XML composition extension
Posted by David Geary <sa...@earthlink.net>.
Le Mar 12, 2005, à 10:56 AM, Matthias Wessendorf a écrit :
> David,
>
> you wrote about your extracted Tiles version.
> Do you have Tiles JSF components and Tags?
No, I don't have anything JSF-specific. The extracted version is simply
decoupled from Struts. Otherwise, it's just vanilla Tiles, except that
I made the default for the flush attribute false, so you can just say:
<tiles:insert definition="some-tile"/> or <tiles:insert
attribute="some-attribute"/>. Ahhhhhh.
> for instance:
>
> most people do:
> <f:subview id="menu">
> <tiles:insert attribute="menu" flush="false" />
> </f:subview>
Yes. You also need a subview when you insert a tile definition.
>
> but you also could provide a *NamingContainer* for Tiles that handles
> the insert.
>
> eg
>
> <jsfTiles: insert id="menu" .../>
>
> where id is also the attribute ?
Something like that would be nice. I've been pondering additions to the
Shale subview tag. Maybe something like: <s:subview tile="some-tile"/>
or <s:subview tile="some-attribute"/>.
david
>
>
> -Matthias
>
> David Geary wrote:
>> I think this is all good stuff, but I'd rather see integration with
>> Tiles instead of reinventing Tiles. Tiles has already covered some of
>> this ground and I see no reason for us to follow.
>> I'd also like to see integration with SiteMesh, which excels at page
>> decoration (as opposed to Tiles, which excels at page composition).
>> I've been talking to the folks on the SiteMesh mailing list about
>> integration between Tiles and SiteMesh, but that of course, is
>> outside the context of JSF. We could do a lot of cool things in Shale
>> to provide a unification of JSF, Tiles and SiteMesh without
>> reinventing any of those technologies.
>> Remember that this mindset is the cornerstone of Shale: Shale aims to
>> augment JSF, not reinvent it, and IMO we should take the same
>> approach with other open-source software that we support.
>> david
>> Le Mar 12, 2005, à 9:44 AM, gvanmatre@comcast.net a écrit :
>>> This would be the second attempt but I would like to start a
>>> discussion on a Shale subview component extension.
>>>
>>> Currently, The shale subview jsf component provides a post-back
>>> method to the prerender method on the ViewController. The id
>>> attribute of the component is assumed as the managed bean name.
>>> This method would be very useful for staging data for the subview
>>> and promoting reuse.
>>>
>>> The extension would add the following features:
>>>
>>> * Fragments of a page could be created using a XML definition and
>>> the same node structure would cover all components making it very
>>> abstract. A top-level component could be represented by a
>>> displayElement node and associated to the logical name of the JSF
>>> component using a componentType attribute.
>>>
>>> * The describing documents could be digested at application startup
>>> and all inheritance resolved at startup. Checks for circular
>>> references would be applied.
>>>
>>> * Like tiles, the metadata defining the subcomponent tree would
>>> support generalization inheritances and also composition
>>> inheritance. Top-level displayElement definitions can extend other
>>> top-level dislpayElements. Composition is formed using the element
>>> node that includes and overrides attributes of the target top-level
>>> node.
>>>
>>> * It would also allow a token replacement feature of the binding EL
>>> so that the metadata describing the construction of a subcomponent
>>> tree could be reused on multiple managed bean names. Featured with
>>> the Shale life cycle methods on the ViewController, would provide
>>> many more reusable view compositions.
>>>
>>>
>>> This composition technique could be used in conjunction with other
>>> methods too. A sample application can be downloaded from the
>>> tracking system. I removed the libraries to make the upload
>>> possible. The example uses the myfaces JSF implementation and the
>>> Shale library.
>>>
>>> http://issues.apache.org/bugzilla/show_bug.cgi?id=33752
>>>
>>> Regards,
>>> Gary VanMatre
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>
> --
> Matthias Weßendorf
> Aechterhoek 18
> DE-48282 Emsdetten
> Germany
> phone: +49-2572-9170275
> cell phone: +49-179-1118979
> email: matzew AT apache DOT org
> url: http://www.wessendorf.net
> callto://mwessendorf (Skype)
> icq: 47016183
>
> ---------------------------------------------------------------------
> 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] subview component XML composition extension
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
David,
you wrote about your extracted Tiles version.
Do you have Tiles JSF components and Tags?
for instance:
most people do:
<f:subview id="menu">
<tiles:insert attribute="menu" flush="false" />
</f:subview>
but you also could provide a *NamingContainer* for Tiles that handles
the insert.
eg
<jsfTiles: insert id="menu" .../>
where id is also the attribute ?
-Matthias
David Geary wrote:
> I think this is all good stuff, but I'd rather see integration with
> Tiles instead of reinventing Tiles. Tiles has already covered some of
> this ground and I see no reason for us to follow.
>
> I'd also like to see integration with SiteMesh, which excels at page
> decoration (as opposed to Tiles, which excels at page composition). I've
> been talking to the folks on the SiteMesh mailing list about integration
> between Tiles and SiteMesh, but that of course, is outside the context
> of JSF. We could do a lot of cool things in Shale to provide a
> unification of JSF, Tiles and SiteMesh without reinventing any of those
> technologies.
>
> Remember that this mindset is the cornerstone of Shale: Shale aims to
> augment JSF, not reinvent it, and IMO we should take the same approach
> with other open-source software that we support.
>
>
> david
>
> Le Mar 12, 2005, à 9:44 AM, gvanmatre@comcast.net a écrit :
>
>> This would be the second attempt but I would like to start a
>> discussion on a Shale subview component extension.
>>
>> Currently, The shale subview jsf component provides a post-back method
>> to the prerender method on the ViewController. The id attribute of
>> the component is assumed as the managed bean name. This method would
>> be very useful for staging data for the subview and promoting reuse.
>>
>> The extension would add the following features:
>>
>> * Fragments of a page could be created using a XML definition and the
>> same node structure would cover all components making it very
>> abstract. A top-level component could be represented by a
>> displayElement node and associated to the logical name of the JSF
>> component using a componentType attribute.
>>
>> * The describing documents could be digested at application startup
>> and all inheritance resolved at startup. Checks for circular
>> references would be applied.
>>
>> * Like tiles, the metadata defining the subcomponent tree would
>> support generalization inheritances and also composition inheritance.
>> Top-level displayElement definitions can extend other top-level
>> dislpayElements. Composition is formed using the element node that
>> includes and overrides attributes of the target top-level node.
>>
>> * It would also allow a token replacement feature of the binding EL
>> so that the metadata describing the construction of a subcomponent
>> tree could be reused on multiple managed bean names. Featured with
>> the Shale life cycle methods on the ViewController, would provide many
>> more reusable view compositions.
>>
>>
>> This composition technique could be used in conjunction with other
>> methods too. A sample application can be downloaded from the tracking
>> system. I removed the libraries to make the upload possible. The
>> example uses the myfaces JSF implementation and the Shale library.
>>
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=33752
>>
>> Regards,
>> Gary VanMatre
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
Matthias Weßendorf
Aechterhoek 18
DE-48282 Emsdetten
Germany
phone: +49-2572-9170275
cell phone: +49-179-1118979
email: matzew AT apache DOT org
url: http://www.wessendorf.net
callto://mwessendorf (Skype)
icq: 47016183
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Shale] subview component XML composition extension
Posted by Craig McClanahan <cr...@gmail.com>.
On Sat, 12 Mar 2005 17:52:17 -0500, Mike Kienenberger
<mk...@alaska.net> wrote:
> David Geary <sa...@earthlink.net> wrote:
> > I think this is all good stuff, but I'd rather see integration with
> > Tiles instead of reinventing Tiles. Tiles has already covered some of
> > this ground and I see no reason for us to follow.
>
> I haven't used JSF enough to see if it fits the same pattern, but the
> component-based frameworks I've used in the past have always made Tiles
> unnecessary. Components are "tiles".
>
The ability to create layout components was indeed one of the
motivations for the API design in JSF. Indeed, if you are using a
templating approach that does *not* allow intermixing static template
text (which is not the case for JSP, or for Tapestry), then you are
pretty much stuck with using components to do your layout for you.
The benefit, on the other hand, is that you can delegate
responsibility for dealing with all the nit-picky details (such as
browser incompatibilities) to your layout components, instead of
having to deal with them in your reusable template text fragments.
> You build a component representing your layout and stick your other layout
> components in it. Then you reference your layout component from your
> general application pages.
>
> An example (and possibly not the best example) from a four-year-old
> Webobjects project. Note that WebObjects (and Tapestry as well from what I
> understand -- RenderBody?) both allow you to access the parent document
> content. It's unclear to me whether JSF is "component-based" enough to do
> this as I haven't built any components with it yet. (Someone asked me this
> question last week, and I haven't had time to find an answer yet.)
When you use <f:subview> in JSF, the components defined in the
dynamically included fragment (a tile, in the case of Tiles) are
grafted in to the component tree of the parent page, so you can use
getParent() recursively to access "outer" state. Is that what you
meant?
>
> Component-based models allow you to do things differently, and I'm just
> wondering if you're dragging some "old-school" methodologies into it
> unnecessarily. Perhaps the answer is that there's no need to reinvent Tiles
> OR integrate Tiles.
There are people who like both philosophies. Especially people that
have existing Tiles based applications that they wish to port. It's
not (yet) clear to me that Shale should only cater to one or the other
approach.
>
> -Mike
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Shale] subview component XML composition extension
Posted by David Geary <sa...@earthlink.net>.
Le Mar 12, 2005, à 3:52 PM, Mike Kienenberger a écrit :
> David Geary <sa...@earthlink.net> wrote:
>> I think this is all good stuff, but I'd rather see integration with
>> Tiles instead of reinventing Tiles. Tiles has already covered some of
>> this ground and I see no reason for us to follow.
>
> I haven't used JSF enough to see if it fits the same pattern, but the
> component-based frameworks I've used in the past have always made Tiles
> unnecessary. Components are "tiles".
Interestingly enough, Tiles was originally called Components.
>
> You build a component representing your layout and stick your other
> layout
> components in it. Then you reference your layout component from your
> general application pages.
>
> An example (and possibly not the best example) from a four-year-old
> Webobjects project. Note that WebObjects (and Tapestry as well from
> what I
> understand -- RenderBody?) both allow you to access the parent document
> content. It's unclear to me whether JSF is "component-based" enough
> to do
> this as I haven't built any components with it yet. (Someone asked me
> this
> question last week, and I haven't had time to find an answer yet.)
>
> Component-based models allow you to do things differently, and I'm just
> wondering if you're dragging some "old-school" methodologies into it
> unnecessarily. Perhaps the answer is that there's no need to reinvent
> Tiles
> OR integrate Tiles.
Perhaps, but assuming we want the same functionality that Tiles
currently provides, such as XML tile definitions, tile inheritance,
role-based tiles, controllers, etc., you're going to have to reinvent
it unless you leverage Tiles somehow. You can have layout components,
certainly, but that would just be the tip of the Tiles iceberg.
I would advocate a layer of Shale components/renderers/variable
resolvers/whatever that integrate with Tiles. Perhaps we could make
layout components an option instead of layout JSP pages, as is the
default for Tiles, although I bet most people would prefer the latter.
david
>
> -Mike
>
> ==================== InternalExternalPageContent
> ======================================
>
> <WEBOBJECT NAME=InternalExternalJSHeader>
> <WEBOBJECT NAME=ShouldShowLeftSideMenuConditional>
> <WEBOBJECT NAME=IsInternalConditional><WEBOBJECT
> NAME=LeftSideMenu>
> </WEBOBJECT></WEBOBJECT>
> <WEBOBJECT NAME=IsExternalConditional><WEBOBJECT
> NAME="LoginPanel">
> </WEBOBJECT></WEBOBJECT>
> <div class="content">
> </WEBOBJECT>
> <WEBOBJECT name=ParentContent></WEBOBJECT>
> <WEBOBJECT NAME=ShouldReturnToLastPageConditional>
> <WEBOBJECT NAME=ReturnToLastPageHyperlink>Return To Last
> Page</WEBOBJECT>
> <p />
> </WEBOBJECT>
> <WEBOBJECT NAME=ShouldReturnToURLConditional>
> <WEBOBJECT NAME=ReturnToURLHyperlink>Return To Last
> Page</WEBOBJECT>
> <p />
> </WEBOBJECT>
>
> <WEBOBJECT NAME=IsInternalConditional><WEBOBJECT
> NAME=InternalFooter>
> </WEBOBJECT></WEBOBJECT>
> <WEBOBJECT NAME=IsExternalConditional><WEBOBJECT
> NAME=ExternalFooter>
> </WEBOBJECT></WEBOBJECT>
> <WEBOBJECT NAME=ShouldShowLeftSideMenuConditional>
> </div>
> </WEBOBJECT>
> </WEBOBJECT>
> =======================================================================
> ========================
>
> ======================Pages in the app that use the
> above======================================
> <!-- <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml11/DTD/transitional.dtd" > -->
> <html>
> <WEBOBJECT NAME=CommonHeadTags>
> <title>DEMO - Online Bill Payment</title>
> Any other <head> tags you want to add or modify
> </WEBOBJECT>
>
> <WEBOBJECT NAME=InternalExternalPageContent>
> This is where your page content would go for any particular
> page...ie,
> <body/> content
> </WEBOBJECT>
> </html>
> =======================================================================
> ============
>
> ---------------------------------------------------------------------
> 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] subview component XML composition extension
Posted by Mike Kienenberger <mk...@alaska.net>.
David Geary <sa...@earthlink.net> wrote:
> I think this is all good stuff, but I'd rather see integration with
> Tiles instead of reinventing Tiles. Tiles has already covered some of
> this ground and I see no reason for us to follow.
I haven't used JSF enough to see if it fits the same pattern, but the
component-based frameworks I've used in the past have always made Tiles
unnecessary. Components are "tiles".
You build a component representing your layout and stick your other layout
components in it. Then you reference your layout component from your
general application pages.
An example (and possibly not the best example) from a four-year-old
Webobjects project. Note that WebObjects (and Tapestry as well from what I
understand -- RenderBody?) both allow you to access the parent document
content. It's unclear to me whether JSF is "component-based" enough to do
this as I haven't built any components with it yet. (Someone asked me this
question last week, and I haven't had time to find an answer yet.)
Component-based models allow you to do things differently, and I'm just
wondering if you're dragging some "old-school" methodologies into it
unnecessarily. Perhaps the answer is that there's no need to reinvent Tiles
OR integrate Tiles.
-Mike
==================== InternalExternalPageContent
======================================
<WEBOBJECT NAME=InternalExternalJSHeader>
<WEBOBJECT NAME=ShouldShowLeftSideMenuConditional>
<WEBOBJECT NAME=IsInternalConditional><WEBOBJECT NAME=LeftSideMenu>
</WEBOBJECT></WEBOBJECT>
<WEBOBJECT NAME=IsExternalConditional><WEBOBJECT NAME="LoginPanel">
</WEBOBJECT></WEBOBJECT>
<div class="content">
</WEBOBJECT>
<WEBOBJECT name=ParentContent></WEBOBJECT>
<WEBOBJECT NAME=ShouldReturnToLastPageConditional>
<WEBOBJECT NAME=ReturnToLastPageHyperlink>Return To Last
Page</WEBOBJECT>
<p />
</WEBOBJECT>
<WEBOBJECT NAME=ShouldReturnToURLConditional>
<WEBOBJECT NAME=ReturnToURLHyperlink>Return To Last Page</WEBOBJECT>
<p />
</WEBOBJECT>
<WEBOBJECT NAME=IsInternalConditional><WEBOBJECT NAME=InternalFooter>
</WEBOBJECT></WEBOBJECT>
<WEBOBJECT NAME=IsExternalConditional><WEBOBJECT NAME=ExternalFooter>
</WEBOBJECT></WEBOBJECT>
<WEBOBJECT NAME=ShouldShowLeftSideMenuConditional>
</div>
</WEBOBJECT>
</WEBOBJECT>
===============================================================================================
======================Pages in the app that use the
above======================================
<!-- <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml11/DTD/transitional.dtd" > -->
<html>
<WEBOBJECT NAME=CommonHeadTags>
<title>DEMO - Online Bill Payment</title>
Any other <head> tags you want to add or modify
</WEBOBJECT>
<WEBOBJECT NAME=InternalExternalPageContent>
This is where your page content would go for any particular page...ie,
<body/> content
</WEBOBJECT>
</html>
===================================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Shale] subview component XML composition extension
Posted by David Geary <sa...@earthlink.net>.
I think this is all good stuff, but I'd rather see integration with
Tiles instead of reinventing Tiles. Tiles has already covered some of
this ground and I see no reason for us to follow.
I'd also like to see integration with SiteMesh, which excels at page
decoration (as opposed to Tiles, which excels at page composition).
I've been talking to the folks on the SiteMesh mailing list about
integration between Tiles and SiteMesh, but that of course, is outside
the context of JSF. We could do a lot of cool things in Shale to
provide a unification of JSF, Tiles and SiteMesh without reinventing
any of those technologies.
Remember that this mindset is the cornerstone of Shale: Shale aims to
augment JSF, not reinvent it, and IMO we should take the same approach
with other open-source software that we support.
david
Le Mar 12, 2005, à 9:44 AM, gvanmatre@comcast.net a écrit :
> This would be the second attempt but I would like to start a
> discussion on a Shale subview component extension.
>
> Currently, The shale subview jsf component provides a post-back method
> to the prerender method on the ViewController. The id attribute of
> the component is assumed as the managed bean name. This method would
> be very useful for staging data for the subview and promoting reuse.
>
> The extension would add the following features:
>
> * Fragments of a page could be created using a XML definition and the
> same node structure would cover all components making it very
> abstract. A top-level component could be represented by a
> displayElement node and associated to the logical name of the JSF
> component using a componentType attribute.
>
> * The describing documents could be digested at application startup
> and all inheritance resolved at startup. Checks for circular
> references would be applied.
>
> * Like tiles, the metadata defining the subcomponent tree would
> support generalization inheritances and also composition inheritance.
> Top-level displayElement definitions can extend other top-level
> dislpayElements. Composition is formed using the element node that
> includes and overrides attributes of the target top-level node.
>
> * It would also allow a token replacement feature of the binding EL
> so that the metadata describing the construction of a subcomponent
> tree could be reused on multiple managed bean names. Featured with
> the Shale life cycle methods on the ViewController, would provide many
> more reusable view compositions.
>
>
> This composition technique could be used in conjunction with other
> methods too. A sample application can be downloaded from the tracking
> system. I removed the libraries to make the upload possible. The
> example uses the myfaces JSF implementation and the Shale library.
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=33752
>
> Regards,
> Gary VanMatre
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org