cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] Improving Views
Date Wed, 20 Aug 2003 09:17:30 GMT
Carsten Ziegeler wrote:

>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



Mime
View raw message