Suggestions for Tiles-concept?

We plan to build a rather large application with OPS and I need to find a solution to assemble web pages from components(at a minimum): header, body, menu, footer (inside the html-body tag).

Coming from a Struts background I am used to the concept of Tiles.

What is the recommended solution / best practice to implement this concept in OPS?

I seems to me that this could be realized using x-inlcude: http://www.orbeon.com/ops/doc/processors-xinclude and then maybe also the resource managers http://www.orbeon.com/ops/doc/reference-resource-managers

Does anybody use the Tiles concept in Orbeon?
Would you please share your solution?

Thank you,
Olaf

-------------------------
Olaf Schroeder
Senior Product Architect
Per-Se Technologies
office: 919-564-2238


pro?gram?mer (n)  -  An organism that can turn caffeine into code.



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

[hidden email] wrote:

 > We plan to build a rather large application with OPS and I need to
 > find a solution to assemble web pages from components(at a minimum):
 > header, body, menu, footer (inside the html-body tag).
 >
 > Coming from a Struts background I am used to the concept of Tiles.
 >
 > What is the recommended solution / best practice to implement this
 > concept in OPS?
 >
 > I seems to me that this could be realized using x-inlcude:
 > http://www.orbeon.com/ops/doc/processors-xinclude and then maybe
 > also the resource managers
 > http://www.orbeon.com/ops/doc/reference-resource-managers
 >
 > Does anybody use the Tiles concept in Orbeon?
 > Would you please share your solution?

Traditionally, aggregation has been done with XSLT. You are right that
this could now be done with XInclude, which is exactly (coincidentally
or not) what I suggested in another thread today. I think what would
work very well is, in the epilogue, to provide the XInclude
processor's "config" input with a static template of your
page. Different user-defined inputs of that processor then feed the
main page content (coming from your page view), header, footer, menu,
etc. Header, footer, etc. could be static or dynamic. The resulting
architecture would be quite elegant!

This said, here at Orbeon we have not actually implemented examples or
applications with this model, but... we should do so, and in fact as
this is an extremely common usage pattern, it should be demonstrated
in the standard epilogue.

If anybody has already experimented with this, we will be happy to
hear about it!

-Erik




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi,

Le mercredi 07 décembre 2005 à 16:23 +0100, Erik Bruchez a écrit :

.../...

> Traditionally, aggregation has been done with XSLT. You are right that
> this could now be done with XInclude, which is exactly (coincidentally
> or not) what I suggested in another thread today. I think what would
> work very well is, in the epilogue, to provide the XInclude
> processor's "config" input with a static template of your
> page. Different user-defined inputs of that processor then feed the
> main page content (coming from your page view), header, footer, menu,
> etc. Header, footer, etc. could be static or dynamic. The resulting
> architecture would be quite elegant!

That's what I meant a looong time ago when I said I wanted to use "style
free stylesheets":
http://sourceforge.net/mailarchive/message.php?msg_id=9589380

The thing that I think we still need is a "pull method" that doesn't
require a declaration that is external to the document.

If I need to declare in the XInclude config all the inputs that I'll be
using to build my page, that removes a good part of the flexibility of
the architecture.

The thing that would be really cool would be to define a URI scheme that
would allow to call pipelines and define simple parameters.

Something like : oxf-page:idpage?param1=val1&param2=val2 could be handy.
That would call the PFC, find page which id is "idpage", handle the
params as in a GET, create the page as usual and use that page as an
input.

Another option could be oxf-pipe:pipe.xpl?param1=val1&param2=val2 which
would execute pipe.xpl passing the arguments as a fake request.  

That something I have found missing when I came from Cocoon and that I
still miss :-) ..

My 0.02 €

Eric
--
Le premier annuaire des apiculteurs 100% XML!
                                                http://apiculteurs.info/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Eric van der Vlist wrote:

 > That's what I meant a looong time ago when I said I wanted to use "style
 > free stylesheets":
 > http://sourceforge.net/mailarchive/message.php?msg_id=9589380
 >
 > The thing that I think we still need is a "pull method" that doesn't
 > require a declaration that is external to the document.
 >
 > If I need to declare in the XInclude config all the inputs that I'll be
 > using to build my page, that removes a good part of the flexibility of
 > the architecture.
 >
 > The thing that would be really cool would be to define a URI scheme that
 > would allow to call pipelines and define simple parameters.
 >
 > Something like : oxf-page:idpage?param1=val1&param2=val2 could be handy.
 > That would call the PFC, find page which id is "idpage", handle the
 > params as in a GET, create the page as usual and use that page as an
 > input.
 >
 > Another option could be oxf-pipe:pipe.xpl?param1=val1&param2=val2 which
 > would execute pipe.xpl passing the arguments as a fake request.
 >
 > That something I have found missing when I came from Cocoon and that I
 > still miss :-) ..

Ah, the push-pull debate ;-) I know where you're coming from, but I
don't see a hugely compelling use case for that... I do see that this
feature gives you something useful, but it also adds more complexity,
which is a new URL scheme.

-Erik




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws