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" keywor
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 se
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 e
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.
Le 8 août 05, à 21:30, Vadim Gritsenko a écrit :
...If you want crusades or jihad (take your pick), start with
XSLGenerator which is already in the trunk for 2 years, 3 months ago
:-)
Actually we *could* rewrite Cocoon in XSLT, not?
-Bertrand, ducking
smime.p7s
Description: S/MIME cryptogra
> 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.
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 scalabi
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
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 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 mig
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 ;-)
From Vadim and Eric: Many (
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 f
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 b
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 no
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
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 contextualizati
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 m
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 f
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
> Why not collapse the entire pipeline into a single component as well, that
> would eliminate a massive amount of bugs and testing time of the Sitemap
> ;o)
>
It's a brillant idea, but it's yours :-D
> Componentization with semantically well-defined contracts in between, is a
> far better than l
> 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 (w
> 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:
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 ther
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 virtu
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 dife
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
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 b
>
> 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
> els
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 specific
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 wil
>
> 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
>
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 DO
>> 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 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.)
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 t
>
> 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
> distinc
BURGHARD Éric wrote:
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 tha
> 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 styles
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 delet
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 contextualizat
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
Kees Broenink wrote:
> Éric,
>
> I tried your solution described below but it does not solve the
> problem...
>
>
>
> will return:
>
>
> 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
>>
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 all tags like div,
script, or inputarea remains unclosed.
I think this is a bug wit
Kees Broenink wrote:
Éric,
I tried your solution described below but it does not solve the
problem...
will return:
So IE is not happy.
I work around this by putting a non-breaking space inside the script
element like this :
PS: Weird thing is that IE does not show the same
Éric,
I tried your solution described below but it does not solve the
problem...
will return:
So IE is not happy.
Regards, Kees
-
public class XMLSerializer2 extends AbstractTextSerializer {
/**
* Set the configurations for this serializer.
*/
public voi
ED] Namens 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 empt
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
>> poss
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 implementi
Title: Bericht
Yes
sorry, my fault. I was using the default configuration of cocoon
2.1.7
I was
not aware of the xhtmlserializer class in blocks/serializers. Now I
am! Thx.
Kees
-Oorspronkelijk bericht-Van: Antonio Fiol Bonnín
[mailto:[EMAIL PROTECTED] Verzonden:
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("
Hello,
Adding to this is an issue with IE and the tag. I did not
search the mail archive nor bugzilla, so maybe it is already addressed
for the next release.
The xhtml serializer will change