cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [Bug] Default-reader depends on JTidy!!!
Date Sun, 11 May 2003 22:35:27 GMT
Stefano Mazzocchi wrote:
> 
> I really don't see Carsten's point.
> 
> We designed the cocoon generator concept *exactly* to adapt streams to
> SAX. Since you *know* what kind of stream you are connecting to, you
> know what generator to use to adapt things.
> 
Yes, and this works fine, but *if* you know what kind of stream you
are connecting to and *if* you know that Cocoon does handle this kind
of stream automatically for you, where is the problem?
I could add that perhaps sometimes you don't know the kind of stream.

> Having a transparent adaptation phase in the source that is not even
> close to be as granularly controllable as our generation approach seems
> wrong to me.
> 
No, no, again, it's *NOT* in the source - it's a utility method of Cocoon
that provides this functionality, so you can decide in your own component,
let's say the file generator, if you want to use this utility method or
not.

The misleading point is, that this method has been added to the Cocoon
SourceResolver interface, so every sitemap component has automatically
access to it.

Now, I still don't see the point, what's wrong with saying:
<map:generate src="thesite.html"/>
Why should I have to use
<map:generate src="thesite.html" type="html"/>
It's in my eyes redundant, because thesite.html contains a mime-type
(html) and that's all I need to know.

Anyway, if I'm the only one who finds this usefull, then ok, remove
the toSAX method from the SourceResolver interface and change all
occurences of the invokation accordingly.

*BUT* then please make sure, that I have the same features/possibilities
than now. One thing is the sitemap but the other is including content
using a transformer like the cinclude transformer.
Currently you can include html pages that are automatically transformed
into xhtml. If you remove the toSAX method mentioned above this is
not possible any. So, a different solution is here needed.
And please, don't tell me that I should include an internal pipeline
that uses the html generator.

This is - in my eyes - not user friendly.

> Too much cocoon machinery has been moved into the sourceresolving and
> xmlutil avalon packages.
I think this is not true.

To all: look at the problems users have with writing applications with
Cocoon. They have the problems mentioned above and it's not a good
choice to create such barriers and make the living of the users more
difficult. Users want - for example cinclude html directly (and please
take this only as one example) and the users don't want complicated
ways of doing it.
With changes like these we make Cocoon harder and harder to use.

But again, if I'm the only one, remove it from the SourceResolver.

Carsten

Mime
View raw message