You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Sebastian Klamar <se...@tux.wh17.tu-dresden.de> on 2003/10/22 21:03:20 UTC
returning to the pipeline after a Serializer based on output size
Hello,
I want to implement a Transformer, that needs to be excecuted more
than once. To know whether the Transformer has to be fired up again
you need to know the output size, produced by an (WML) Serializer (and
WML Compile). The idea behind this is to fragment a page into smaller
parts, so devices with small memory and display resources can display
the page. (The fragmented pages are stored on the server and delivered
separately. Navigation between the fragments is done via inserted
hyperlinks. There is also needed a FragementCacheManager that
delivers the other fragmented pieces of one page -- but that's the
second problem *g)
How can I analyze the data produced at the very end of the chain (in
case of producing WML after additionally compiling it) and return to the
FragmentationTransformer in the Cocoon pipeline?
Maybe the following chart can help you to understand what I want to
achieve:
Generators
|
V
other Transformers
|
V
FragmentationTransformer <-----------------------.
| param \
V \
WML Serializer (XMLSerializer) \
| \
V \
WMLCompiler \
| \
| \
X check the size of the serialized/compiled |
character stream |
if output > MAX return to FragmentationTransformer
else deliver to client (which has MAX bytes of
memory resources)
Or in good ol' do-while-style:
saxDocument = somePreTransformer.act(...);
do {
fragmentedSaxDocument = FragmentationTransformer.act(saxDocument, param);
wmlDocument = WMLSerializer.act(fragmentedSaxDocument);
compiledData = WMLCompiler.act(wmlDocument);
} while (compiledData.getSize() > MAX);
The WMLCompiler can't be part of the Cocoon pipeline, can it? Maybe
implement an additional Serializer that does WML-Serializing and
compiling in one?
Matchers and Selectors do only act on the request. Maybe I have to
check the output (compiled data) in an external servlet and recalling
the Cocoon Servlet again? Not good.
What about Readers? They do act on character data, only. Can you place
Readers *after* a Serializer? Depending of the output of the Serializer
you jump back to the FragmentationTransformer in the pipeline. Does
Cocoon's sitemap concept/logic support this? I've read that Readers are
applied outside of the SAX pipeline (because they are a combination of a
generator and a serializer) :-(
I'm new to Cocoon (but supported by the great Cocoon Developer's
Handbook by Lajos Moczar and Jeremy Aston). Therefore I still haven't
got a good overall knowledge on Cocoon's sitemap logic and component
interaction needed by the described algorithm.
TIA -- Sebastian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: returning to the pipeline after a Serializer based on output
size
Posted by Oleg Dulin <du...@olegdulin.com>.
Why not put the transformation logic into XSL ? At the end of the
transform you should know how much you produce; and my guess is that the
size of the serialized object is linearly proportional to the size of
the WML document.
Oleg
Sebastian Klamar wrote:
> Hello,
>
> I want to implement a Transformer, that needs to be excecuted more
> than once. To know whether the Transformer has to be fired up again
> you need to know the output size, produced by an (WML) Serializer (and
> WML Compile). The idea behind this is to fragment a page into smaller
> parts, so devices with small memory and display resources can display
> the page. (The fragmented pages are stored on the server and delivered
> separately. Navigation between the fragments is done via inserted
> hyperlinks. There is also needed a FragementCacheManager that
> delivers the other fragmented pieces of one page -- but that's the
> second problem *g)
>
> How can I analyze the data produced at the very end of the chain (in
> case of producing WML after additionally compiling it) and return to the
> FragmentationTransformer in the Cocoon pipeline?
>
> Maybe the following chart can help you to understand what I want to
> achieve:
>
> Generators
> |
> V
> other Transformers
> |
> V
> FragmentationTransformer <-----------------------.
> | param \
> V \
> WML Serializer (XMLSerializer) \
> | \
> V \
> WMLCompiler \
> | \
> | \
> X check the size of the serialized/compiled |
> character stream |
> if output > MAX return to FragmentationTransformer
> else deliver to client (which has MAX bytes of
> memory resources)
>
> Or in good ol' do-while-style:
>
> saxDocument = somePreTransformer.act(...);
> do {
> fragmentedSaxDocument = FragmentationTransformer.act(saxDocument, param);
> wmlDocument = WMLSerializer.act(fragmentedSaxDocument);
> compiledData = WMLCompiler.act(wmlDocument);
> } while (compiledData.getSize() > MAX);
>
> The WMLCompiler can't be part of the Cocoon pipeline, can it? Maybe
> implement an additional Serializer that does WML-Serializing and
> compiling in one?
>
>
> Matchers and Selectors do only act on the request. Maybe I have to
> check the output (compiled data) in an external servlet and recalling
> the Cocoon Servlet again? Not good.
>
> What about Readers? They do act on character data, only. Can you place
> Readers *after* a Serializer? Depending of the output of the Serializer
> you jump back to the FragmentationTransformer in the pipeline. Does
> Cocoon's sitemap concept/logic support this? I've read that Readers are
> applied outside of the SAX pipeline (because they are a combination of a
> generator and a serializer) :-(
>
> I'm new to Cocoon (but supported by the great Cocoon Developer's
> Handbook by Lajos Moczar and Jeremy Aston). Therefore I still haven't
> got a good overall knowledge on Cocoon's sitemap logic and component
> interaction needed by the described algorithm.
>
>
> TIA -- Sebastian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org