It's seems we have RT Time :)
kewl ;-)
With views we have a nice sitemap feature that imho can be improved as well:
One major disadvantage currently is that views are not inherited to
subsitemaps, so I:
****
Views should be inherited and can be extended/overwritten in subsitemaps like any other component.
****
+1.
Relating this to the newly introduced virtual components, we can consider the view definition as a virtual serializer.
Example : <map:serializers> <map:serializer type="xml" src="oacs.XMLSerializer"/> <map:serializer type="pretty-xml"> <map:transform type="xslt" src="xml2pretty.xsl"/> <map:serialize type="xml"/> </map:serializer> </map:serializers>
<map:views>
<map:view name="content" from-label="content" serializer="xml"/>
<map:view name="pretty-content" from-label="content" serializer="pretty-xml"/>
</map:views>
I also thought about merging serializers and view definitions, since a view is "just" a serializer whose call is triggered by a specific label and not an explicit sitemap statement. But this really seems as mixing concerns and leads to a clumsy syntax.
Views are used for different scenarios; they provide a different ending
of your pipeline. This is e.g. useful for debugging. Now by default
the content view is enabled (for the main sitemap), and most times
this view is not disabled when the application goes in production,
so a user can invoke this view on deployed applications and see the
output of the generator. But, this might contain sensitive data which is
not intended to be seen by the average user. So it makes sense to have a way to turn off views. But at the same time you might need
views in different areas of your application, so:
**** Views can have a default state: enabled or disabled that can be set in the sitemap: <map:views default="enabled"> (or disabled)
This default can be overwritten on a map:pipeline base: <map:pipeline views="disabled"> (or enabled)
In addition, you can allow only some views, like: <map:pipeline allow-views="x,z"> ****
This reminds me of something that was proposed a while ago, which is "running modes" [1]. The running mode is an immutable system-wide value (defined e.g. in web.xml or as with a system property) that can be used to activate/deactivate particular features or configurations.
Implementation-wide, we could envision this as a filter applied when loading configuration files, scanning for "if-running-mode" and "unless-running-mode" attributes. These attributes would contain a list of comma-separated modes which would repectly keep or remove the corresponding XML element from the document used by Cocoon.
<map:views> <map:view name="content" if-running-mode="dev"> ... </map:view> <map:view name="indexable-content"> </map:view> </map:views>
This could be used for many things :
- logging : select the logkit log levels and / or targets depending on the running mode
- profiling : switch the pipeline used to profiling mode without requiring change in the sitemaps
- deployment : choose datasources configurations depending on the running mode
- etc
Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103175546321320&w=2
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
