[RT] Improving Views

[Carsten Ziegeler <cz...@s-und-n.de>]

It's seems we have RT Time :)

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.
****

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">
****

And now you :)

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG
http://radio.weblogs.com/0107211/

Re: [RT] Improving Views

[Sylvain Wallez <sy...@anyware-tech.com>]

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

Re: [RT] Improving Views

[Vadim Gritsenko <va...@verizon.net>]

Upayavira wrote:

> leo leonid wrote:


<snip/>

>> I think it is not sufficient to have views that can be 
>> enabled/disabled. Sometimes other components depend on certain views 
>> (like the Lucene indexer) and so you can't disable. Maybe we need a 
>> sort of access restriction mechanism.
>
>
> Like <map:pipeline views="internal"> or <map:pipeline 
> allow-views="x,y" internal-views="a,b">?
>
> The same would apply to the command line/bean, which requires link 
> view, but which you might not want to expose to the public.


Those views actually were intended to be exposed to the public. So 
public can intellegently crawl your website, or aggregate parts of your 
website, or index your website (think search engine which indexes 
content, not navigation bar). So Cocoon running on the user's host could 
interoperate with another Cocoon instance on another host.

But yes, sometimes you may want to disable this view here or that view 
there.

Vadim

Re: [RT] Improving Views

[Upayavira <uv...@upaya.co.uk>]

leo leonid wrote:

>
> On Mittwoch, August 20, 2003, at 09:07  Uhr, Carsten Ziegeler wrote:
>
>> It's seems we have RT Time :)
>>
>> 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.
>> ****
>>
>> 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">
>> ****
>>
>> And now you :)
>>
>
> I think it is not sufficient to have views that can be 
> enabled/disabled. Sometimes other components depend on certain views 
> (like the Lucene indexer) and so you can't disable. Maybe we need a 
> sort of access restriction mechanism.

Like <map:pipeline views="internal"> or <map:pipeline allow-views="x,y" 
internal-views="a,b">?

The same would apply to the command line/bean, which requires link view, 
but which you might not want to expose to the public.

Upayavira

Re: [RT] Improving Views

[leo leonid <te...@leonid.de>]

On Mittwoch, August 20, 2003, at 09:07  Uhr, Carsten Ziegeler wrote:

> It's seems we have RT Time :)
>
> 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.
> ****
>
> 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">
> ****
>
> And now you :)
>

I think it is not sufficient to have views that can be 
enabled/disabled. Sometimes other components depend on certain views 
(like the Lucene indexer) and so you can't disable. Maybe we need a 
sort of access restriction mechanism.

/Leo




> Carsten
>
> Carsten Ziegeler
> Open Source Group, S&N AG
> http://radio.weblogs.com/0107211/
>