You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Vadim Gritsenko <va...@verizon.net> on 2002/04/06 06:30:29 UTC

Serializer configuration, was: [status & RT] design challenges

> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> 
> Stefano Mazzocchi wrote:

<skip/>

> > 1) serializers don't have full access to the component environment 
> > and some want this to be changed
> >
> 
> The major need is to be able to access the SourceResolver. I haven't
> seen any good use case where a Serializer needs to access something
else
> in the environment.

Many of the Cocoon components accept configuration when declared in the
components part of the sitemap. Examples:
TraxTransformer:
  <use-request-parameters>false</use-request-parameters>
I18nTransformer:
  <catalogue-name>messages</catalogue-name>
HTMLSerializer:
  <buffer-size>1024</buffer-size>
SVGSerializer:
  <parameter name="quality" type="float" value="0.9"/>

All of these components (with one exception) allow overriding global
defaults at the moment of component usage:

TraxTransformer:
  <map:parameter name="use-request-parameters" value="false"/>
I18nTransformer:
  <map:parameter name="catalogue-name" value="messages"/>

Now you can guess the exception: serializers. They are the only
components which do not allow overriding defaults.

The question is where the error in design is. Is it in allowing
serializer to have a configuration or in disabling the ability to
override this configuration?

Comments? (Stefano?)

Vadim 

<skip/>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: Serializer configuration, was: [status & RT] design challenges

Posted by Stefano Mazzocchi <st...@apache.org>.
Vadim Gritsenko wrote:
> 
> > From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> >
> > Stefano Mazzocchi wrote:
> 
> <skip/>
> 
> > > 1) serializers don't have full access to the component environment
> > > and some want this to be changed
> > >
> >
> > The major need is to be able to access the SourceResolver. I haven't
> > seen any good use case where a Serializer needs to access something
> else
> > in the environment.
> 
> Many of the Cocoon components accept configuration when declared in the
> components part of the sitemap. Examples:
> TraxTransformer:
>   <use-request-parameters>false</use-request-parameters>
> I18nTransformer:
>   <catalogue-name>messages</catalogue-name>
> HTMLSerializer:
>   <buffer-size>1024</buffer-size>
> SVGSerializer:
>   <parameter name="quality" type="float" value="0.9"/>
> 
> All of these components (with one exception) allow overriding global
> defaults at the moment of component usage:
> 
> TraxTransformer:
>   <map:parameter name="use-request-parameters" value="false"/>
> I18nTransformer:
>   <map:parameter name="catalogue-name" value="messages"/>
> 
> Now you can guess the exception: serializers. They are the only
> components which do not allow overriding defaults.
> 
> The question is where the error in design is. Is it in allowing
> serializer to have a configuration or in disabling the ability to
> override this configuration?

Good point, I agree this is an unnecessary drawback.

Ok, listen: if enough people whan this to change, maybe it's time to do
it.

I think you and Sylvain know more about the internals of the pipelines
that I do, so I'll turn my votes on the serializers to -0 and trust you
guys.

Just one think: keep caching concerns *very* clear in mind.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: Serializer configuration, was: [status & RT] design challenges

Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:

>>From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>>
>>Stefano Mazzocchi wrote:
>>
>
><skip/>
>
>>>1) serializers don't have full access to the component environment 
>>>and some want this to be changed
>>>
>>The major need is to be able to access the SourceResolver. I haven't
>>seen any good use case where a Serializer needs to access something
>>else in the environment.
>>
>
>Many of the Cocoon components accept configuration when declared in the
>components part of the sitemap. Examples:
>TraxTransformer:
>  <use-request-parameters>false</use-request-parameters>
>I18nTransformer:
>  <catalogue-name>messages</catalogue-name>
>HTMLSerializer:
>  <buffer-size>1024</buffer-size>
>SVGSerializer:
>  <parameter name="quality" type="float" value="0.9"/>
>
>All of these components (with one exception) allow overriding global
>defaults at the moment of component usage:
>
>TraxTransformer:
>  <map:parameter name="use-request-parameters" value="false"/>
>I18nTransformer:
>  <map:parameter name="catalogue-name" value="messages"/>
>
>Now you can guess the exception: serializers. They are the only
>components which do not allow overriding defaults.
>
>The question is where the error in design is. Is it in allowing
>serializer to have a configuration or in disabling the ability to
>override this configuration?
>
>Comments? (Stefano?)
>

Good point, Vadim. This is the same kind of issue you raised with view 
labels : if we want to use the same serializer with different 
configurations, we have to create new components, with the associated 
resource overhead, while allowing Serializers to have parameters would 
avoid it.

Sylvain

-- 
Sylvain Wallez
 Anyware Technologies                  Apache Cocoon
 http://www.anyware-tech.com           mailto:sylvain@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org