Tiles is one of these tiny powerful tools everybody needs but not everybody knows that he needs it :) Using Tiles makes sense and there is not really a general reason against using Tiles, but there are also some reasons to use Patchwork within Apache Cocoon:
| [top] |
Aggregation is a very good solution to merge "non-design" XML documents, but for "design-documents" like (X)HTML templates it has some big disadvantages: With aggregation you can create your layout from different single files but you don't have a single master file that defines the main structure and includes all other files. Furthermore, implementing nested and conditional aggregations can become very complex. Think about the steps you would have to do for such an easy task like including into the part "header" another part "banner", but only if the flag "useBanner" was set before. More than two of such nested and conditional includes and this leads to a huge, nearly unreadable sitemap!
It doesn't support layout inheritance.
| [top] |
The CInlcude (or XInclude) mechanism is very useful to include a XML document into another but that's it. It has no mechanism for defining the include structure at a central place and doesn't support layout inheritance.
| [top] |
Also JXTemplate's import mechanism is only a include mechanism, not more but not less. It has no mechanism for defining the include structure at a central place and doesn't support layout inheritance. But you can use this mechanism in conjunction with Patchwork. See here. Using JXTemplate in conjunction with Patchwork reduces the need of different sitemap components and allows you to do most of the "design work" using JXTemplate or any other templating system that supports includes and JavaBeans.
| [top] |
Sure, but currently only the Content Provider of type "xml" is available. You can write very easily your own Content Provider that generates and returns a JavaBean. See here for the details.
| [top] |
Yes, use the Content Provider "xml" and its attribute "src" and point to a Cocoon pipeline using the protocol schema "cocoon:/". See here.
| [top] |
Contentwork doesn't prevent you from using XSLT. XSLT does a great job, but in some situations (especially in a webdesign-oriented development team) using XSLT to bring your XML data and HTML templates together is not the best approach. Because of XSLT "wraps" arround your templates and therefore reading and maintaining them is not easily possible without XSLT knowledge. Contentwork's intention is to solve exactly this problem in a way that you can "inject" the (XML) content into your templates and then transform the content using the template's language like you would do with JavaBeans. The templates itself will stay still in a way where they're readable by any designer with HTML knowledge. Contentwork is not designed to become a replacement for XSLT at all.
Please see also here.
| [top] |
No. Contentwork allows you to provide content to your website without the need of writing code or pipelines at your own. But as soon as you have to involve some user interaction logic or to trigger business logic for example, a Controller must do that job. But you can use Contentwork in conjunction with a Controller, no problem.
| [top] |
