On 09.08.2005 02:17, Vadim Gritsenko wrote:
From the pipeline's POV it's not 1:1 as the serializer decides to
which output format the XML is serialized, so it is 1:n, so the output
is also not predictable for the pipeline.
Output of the serializer is never predictable, otherwise no need for
Joerg Heinicke wrote:
On 08.08.2005 21:30, Vadim Gritsenko wrote:
...
Moreover, I don't see why go all religious on simple and (as it seems)
useful idea of XSLSerializer. We do have FOP, Batik, etc serializers -
why not Trax.
I don't see how they compare.
Furthermore there were reasons
Vadim Gritsenko wrote:
Joerg Heinicke wrote:
On 07.08.2005 19:22, BURGHARD Éric wrote:
Completely wrong. If you find a 1:1 relation between a svg and a
bitmap, go
ahead man, you're rich. For me a svg serialization is not
reversible, you
loose layers, labels, structure and of course
From Vadim and Eric: Many (most?) serializers are not reversible and
therefore there should be no prohibition on yet another seemingly useful
serializer based upon XSLT and its output element.
In fact, if i try to summarize this thread, we are just talking about
implementation language.
On 09.08.2005 02:03, Vadim Gritsenko wrote:
* Serializers are allowed to implement SitemapModelComponent
* SitemapModelComponent has setup method
* setup() method passes src parameter - src attribute from the sitemap.
Now, from Cocoon design perspective, this is all legal and supported.
Joerg Heinicke wrote:
I still don't see why we should add a component to the Cocoon codebase,
where we know from the beginning that it is not best practice (better
formulation than my problematic, but meaning the same).
I'll rephrase what I wrote in one short sentence:
Anything can be
Vadim Gritsenko wrote:
Joerg Heinicke wrote:
I still don't see why we should add a component to the Cocoon
codebase, where we know from the beginning that it is not best
practice (better formulation than my problematic, but meaning the
same).
I'll rephrase what I wrote in one short
On 10.08.2005 01:44, Antonio Gallardo wrote:
OK Guys, I am wondering if all the developers are following this very
interesting thread.
The pure number of mails speaks for the importance of this thread ;-)
I will suggest to start a new one and include in the
title the TraxTransformer
Joerg Heinicke wrote:
On 07.08.2005 19:22, BURGHARD Éric wrote:
Completely wrong. If you find a 1:1 relation between a svg and a
bitmap, go
ahead man, you're rich. For me a svg serialization is not reversible, you
loose layers, labels, structure and of course scalability.
Man, 1:1 does not
On 05.08.2005 13:49, BURGHARD Éric wrote:
I wrote a much more powerfull solution: the XSLSerializer, which let you
control the serialization through an xsl stylesheet (an so use the
xsl:output tag as well as some template rules to make final cleanup like
namespace deletion or href
On 08.08.2005 21:30, Vadim Gritsenko wrote:
Completely wrong. If you find a 1:1 relation between a svg and a
bitmap, go
ahead man, you're rich. For me a svg serialization is not reversible,
you
loose layers, labels, structure and of course scalability.
Man, 1:1 does not mean that you can go
Joerg Heinicke wrote:
On 08.08.2005 21:30, Vadim Gritsenko wrote:
Completely wrong. If you find a 1:1 relation between a svg and a
bitmap, go
ahead man, you're rich. For me a svg serialization is not
reversible, you
loose layers, labels, structure and of course scalability.
Man, 1:1 does
Forgive me for jumping in, but people seem to be talking past one
another. I don't think you are talking about the same issue(s). Correct
me if I'm wrong.
Vadim Gritsenko wrote:
Joerg Heinicke wrote:
On 08.08.2005 21:30, Vadim Gritsenko wrote:
Completely wrong. If you find a 1:1 relation
On 08.08.2005 23:10, Vadim Gritsenko wrote:
XSLT serialization (as per spec Eric quoted) provides a way for one way
1:1 transformation of xml into the desired view format exactly in the
same way as batik transforms svg into png. XSLT has more capabilities,
one even might say that it allows
Roy G. Biv wrote:
Forgive me for jumping in, but people seem to be talking past one
another. I don't think you are talking about the same issue(s). Correct
me if I'm wrong.
I'm just arguing here - you are in better position to see what we are arguing
about ;-)
snip/
From Vadim and Eric:
Joerg Heinicke wrote:
On 08.08.2005 23:10, Vadim Gritsenko wrote:
XSLT serialization (as per spec Eric quoted) provides a way for one
way 1:1 transformation of xml into the desired view format exactly in
the same way as batik transforms svg into png. XSLT has more
capabilities, one even
I don't understand here. How could i modify a model with an xsl
transformation (and by extension an xsl serialization) ? XSL is for
generating views from a sax representation of a model (not to be confused
with the model itself. It's generated at the beginning of the pipeline by
the
On 07.08.2005 10:53, BURGHARD Éric wrote:
Perhaps I overused the term model. I was referring more to the
_Document_Object_ Model (DOM) represented by the various stages of the
SAX stream. A generator creates one DOM, a transformer converts that
DOM into another, and a serializer takes the DOM
Of course serializers do transformations, you already wrote it: from SAX
to bytes. But there is one important difference: The behaviour of a
serializer (and at the end the output) is absolutely predictable. If you
feed the same SAX events into a specific serializer you will always get
the
BURGHARD Éric wrote:
If you look at the core components, no one follow such a hard constraint.
Some serializers do radical transformation (svg2jpeg, links, ...), while
some transformers only do very light transformation (encodeurl, i18n, ...).
If you take the links serializer for example you
On 07.08.2005 14:51, BURGHARD Éric wrote:
Of course serializers do transformations, you already wrote it: from SAX
to bytes. But there is one important difference: The behaviour of a
serializer (and at the end the output) is absolutely predictable. If you
feed the same SAX events into a
You know what I meant: A serializer just changes the representation of
the data but does not change the data itself - while this is of course
not true for the transformers. When you setup your pipeline it is a
1:1-relation of SAX input to byte output and does not depend on anything
else.
On 07.08.2005 19:22, BURGHARD Éric wrote:
Completely wrong. If you find a 1:1 relation between a svg and a bitmap, go
ahead man, you're rich. For me a svg serialization is not reversible, you
loose layers, labels, structure and of course scalability.
Man, 1:1 does not mean that you can go in
BURGHARD Éric wrote:
Of course serializers do transformations, you already wrote it: from SAX
to bytes. But there is one important difference: The behaviour of a
serializer (and at the end the output) is absolutely predictable. If you
feed the same SAX events into a specific serializer you will
BURGHARD Éric wrote:
Again, there is no conceptual difference between generator, transformer,
serializer, apart the type of their position in the pipeline and so the
type of their io. They ALL do transformations otherwise they would be very
unusefull.
Yep. They share a lot in common. The
On Sunday 07 August 2005 20:51, BURGHARD Éric wrote:
He was just wondering if this thread was about virtual serialization. It's
not.
What IS it about??
XSLSerializer is a full featured serializer which can play the role of
a serializer in a virtual serializer if you really want to
On Monday 08 August 2005 01:22, BURGHARD Éric wrote:
standard serializers are bugged.
If we have bugs in the serializers, then let's address it.
If we need more types of serializers, then we address that.
Eric, I think the only thing that people get hung up on is the suggestion
that there
I was not wondering, I saw your request exaclty as a virtual
serializers usecase. This is something we want to address for cocoon 2.2.
Ok ;-). So 'Is this a virtual component ?' was not a question (i'm joking).
Thanks for (re)joining this discussion.
I believe, I understand your point:
2 points:
1-Nobody is telling you cannot use your own serializers.
2- I agree the current standard serializer has bugs. I tried to fix
them. I met problems into xalan internals and well, it is a very
long story. Few weeks ago, I spent most part of 15 nights trying to fix
that (weekend
Niclas Hedhman wrote:
On Monday 08 August 2005 01:22, BURGHARD Éric wrote:
standard serializers are bugged.
If we have bugs in the serializers, then let's address it.
If we need more types of serializers, then we address that.
Read my answer to antonio, it will perhaps be more clear.
BURGHARD Éric wrote:
2 points:
1-Nobody is telling you cannot use your own serializers.
2- I agree the current standard serializer has bugs. I tried to fix
them. I met problems into xalan internals and well, it is a very
long story. Few weeks ago, I spent most part of 15 nights trying to
What XMLSerializer are you talking about? The one in the serializers
block or the default one?
org.systheo.cocoon.serialization.XMLSerializer
I wrote a much more powerfull solution: the XSLSerializer, which let you
control the serialization through an xsl stylesheet (an so use the
Kees Broenink wrote:
Éric,
I tried your solution described below but it does not solve the
script/script problem...
script type=text/javascript src=/bxs/3_0_1/bpc/boot.js/script
will return:
script type=text/javascript src=/bxs/3_0_1/bpc/boot.js
xml:space=preserve /
So IE is not
BURGHARD Éric wrote:
What XMLSerializer are you talking about? The one in the serializers
block or the default one?
umh, i went to quickly :-), this is
org.apache.cocoon.serialization.XMLSerializer
On 06.08.2005 11:03, BURGHARD Éric wrote:
I wrote a much more powerfull solution: the XSLSerializer, which let you
control the serialization through an xsl stylesheet (an so use the
xsl:output tag as well as some template rules to make final cleanup like
namespace deletion or href
Joerg Heinicke wrote:
On 06.08.2005 11:03, BURGHARD Éric wrote:
I wrote a much more powerfull solution: the XSLSerializer, which
let you
control the serialization through an xsl stylesheet (an so use the
xsl:output tag as well as some template rules to make final cleanup
like
namespace
1. I was talking about the concept, not implementation details. And from
that POV a stylesheet should not influence the pipeline. IMO It's plain
wrong to set the output format in the stylesheet.
2. But yes, I was missing the most important point in your approach
thinking that any stylesheet
I agree with Joerg here; by providing the author with the ability to use
any .xsl for serialization, you're allowing the serializer to control
not only how the model is serialized, but to modify the model itself
(which is the role of transformers). This essentially removes the
distinction
BURGHARD Éric wrote:
I agree with Joerg here; by providing the author with the ability to use
any .xsl for serialization, you're allowing the serializer to control
not only how the model is serialized, but to modify the model itself
(which is the role of transformers). This essentially removes
On 07.08.2005 01:27, Jason Johnston wrote:
But the important thing is that using an XSLT internally is merely an
implementation detail. Exposing the XSLT implementation to users is
what Joerg and I take issue with. (Don't mean to speak for you here,
Joerg, correct me if I'm misquoting you.)
Thorsten Scherler wrote:
On Tue, 2005-08-02 at 11:25 +0200, Antonio Fiol Bonnín wrote:
Hello,
I am finding a problem with empty elements when serving content with
the text/html content type on Firefox.
For example, collapsed empty div elements cause havoc in firefox. A
possible
BURGHARD Éric
Verzonden: Friday, August 05, 2005 1:50 PM
Aan: dev@cocoon.apache.org
Onderwerp: Re: Suggestion for XHTMLSerializer
Thorsten Scherler wrote:
On Tue, 2005-08-02 at 11:25 +0200, Antonio Fiol Bonnín wrote:
Hello,
I am finding a problem with empty elements when serving content
Éric,
I tried your solution described below but it does not solve the
script/script problem...
script type=text/javascript src=/bxs/3_0_1/bpc/boot.js/script
will return:
script type=text/javascript src=/bxs/3_0_1/bpc/boot.js
xml:space=preserve /
So IE is not happy.
Regards, Kees
Kees Broenink wrote:
Éric,
I tried your solution described below but it does not solve the
script/script problem...
script type=text/javascript src=/bxs/3_0_1/bpc/boot.js/script
will return:
script type=text/javascript src=/bxs/3_0_1/bpc/boot.js
xml:space=preserve /
So IE is not happy.
On 05.08.2005 13:49, BURGHARD Éric wrote:
In fact the XMLSerializer didn't take the 'method' parameter into account.
At least in saxon8 (never test with other xslt processor, but it should
work too), if you put xsl:output method=xhtml/ all tags like div,
script, or inputarea remains unclosed.
On Tue, 2005-08-02 at 11:25 +0200, Antonio Fiol Bonnín wrote:
Hello,
I am finding a problem with empty elements when serving content with
the text/html content type on Firefox.
For example, collapsed empty div elements cause havoc in firefox. A
possible workaround would be implementing
Hello,
I am finding a problem with empty elements when serving content with
the text/html content type on Firefox. For example, collapsed empty div
elements cause havoc in firefox. A possible workaround would be
implementing the compatibility guidelines indicated in the W3C
recommendations.
In
src=/bxs/3_0_1/bpc/boot.js/
This will break loading the JS in IE.
Kees
-Oorspronkelijk bericht-
Van: Antonio Fiol Bonnín [mailto:[EMAIL PROTECTED]
Verzonden: Tuesday, August 02, 2005 11:26 AM
Aan: dev@cocoon.apache.org
Onderwerp: Suggestion for XHTMLSerializer
Hello,
I am finding
Maybe I read the code the wrong way. What I understood was:
public void endElementImpl(String uri, String local, String qual) throws SAXException {
[...]
if (XHTML1_NAMESPACE.equals(uri)) {
if ((local.equalsIgnoreCase(textarea)) ||
(local.equalsIgnoreCase(script)) ||
Title: Bericht
Yes
sorry, my fault. I was using the default configuration of cocoon
2.1.7
map:serializer logger="sitemap.serializer.xhtml"
mime-type="text/html" name="xhtml" pool-max="64"
src=""
I was
not aware ofthe xhtmlserializer class in blocks/serializers.Now I
am! Thx.
Kees
50 matches
Mail list logo
