Re: [RT] Improving Views
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, SN AG http://radio.weblogs.com/0107211/
Re: [RT] Improving Views
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
Sylvain Wallez wrote: 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 like this, and while we're at it - I'd also like to see the ability to define different views with the same name. I don't think this is possible at present. e.g. map:views map:view name=search from-label=tei serializer=tei-search/ map:view name=search from-label=html serializer=html-search/ map:view name=search from-label=svg serializer=svg-search/ /map:views When accessing a pipeline using a view called X, the pipeline processor could branch off from the main pipeline at the FIRST label Y for which there exists a map:view with @name=X and @from-label=Y. This would make it easy to define e.g. a search view of heterogeneous pipelines, with different types of content. Typically the label attributes in the pipeline would refer to the TYPE of the content at that stage in the pipeline. Cheers Con
