Serializer needs to be a SitemapModelComponent ?

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

Team,

Please find below an answer I gave to a colleague on cocoon-users. After 
more thoughts, I think to have found a good example of a Serializer that 
could take advantage of both Parameters and SourceResolver...

Due to a bug in IE that fails to display PDFs when there's no 
Content-Length header, FOPSerializer.shouldSetContentLength() always 
returns true. For large documents (several hundred pages in our case), 
this is a memory hog that can be avoided if we detect that the browser 
hasn't this bug, e.g. using a matcher.

But for this, the serializer needs to accept Parameters, which isn't 
possible. Yes, I know, the result of this matcher can parameterize a 
transformer just before on the serializer, but this is really not user 
friendly.

Also, the FOPSerializer accepts a configuration file describing font 
metrics. Since a serializer has no access to the SourceResolver, *the 
absolute file path* must be given in the sitemap ! This goes totally 
against the modularity that is currently under discussion. There's even 
a big warning in the docs that users should manually destroy the cache 
if they change the configuration file, since the serializer has no way 
to tell the cache that this file changed.

What are your thoughts ?

Sylvain


Olivier Rossel wrote:

> I wonder if FOP serializer can stream PDF documents instead of 
> buffering the whole document before sending it.
> I was told that it is because of a nasty bug in IE/Acrobat plug-in. 
> But the FOP Serializer has already the capability.
>
> Is it true?
> Can this behaviour be enabled?

Yes, Olivier, I will make it configurable.
(damn, he's 10 meters away from me and sends the question to the list ;)

Does someone know the status of this bug in recent IE versions ?

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

RE: Serializer needs to be a SitemapModelComponent ?

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

> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> 
> From: "Sylvain Wallez" <sy...@anyware-tech.com>
> 
> > Please find below an answer I gave to a colleague on cocoon-users.
After
> > more thoughts, I think to have found a good example of a Serializer
that
> > could take advantage of both Parameters and SourceResolver...
> 
> <snipped-real-life-needs-I-agree-with/>
> 
> I have another need: I have a Serializer that takes a JComponent and
renders
> it to JPEG directly without using SVG.
> I need to specify a configuration, and have access to the class that
may not
> be in the Classpath.
> 
> Are there any technical reasons that still stand in the way for making
> Serializer a SitemapModelComponent?

I don't think so. Moreover, CachingStreamPipeline.java already checks
whether Serializer is Cacheable or not, and processes it accordingly.
This means, that no caching issues should arise.

I could try:
1. Add SitemapModelComponent to the Serializer,
2. Call serializer's setup() in the AbstractStreamPipeline's
setupPipeline(),
3. Did I forget something else?
4. test how it works :)

Vadim

> 
> --
> Nicola Ken Barozzi                   nicolaken@apache.org
>             - verba volant, scripta manent -
>    (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------


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

Re: Serializer needs to be a SitemapModelComponent ?

[Nicola Ken Barozzi <ni...@apache.org>]

From: "Sylvain Wallez" <sy...@anyware-tech.com>

> Please find below an answer I gave to a colleague on cocoon-users. After
> more thoughts, I think to have found a good example of a Serializer that
> could take advantage of both Parameters and SourceResolver...

<snipped-real-life-needs-I-agree-with/>

I have another need: I have a Serializer that takes a JComponent and renders
it to JPEG directly without using SVG.
I need to specify a configuration, and have access to the class that may not
be in the Classpath.

Are there any technical reasons that still stand in the way for making
Serializer a SitemapModelComponent?

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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