cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [Bug] Default-reader depends on JTidy!!!
Date Mon, 12 May 2003 23:52:04 GMT
on 5/11/03 5:35 PM Carsten Ziegeler wrote:

> 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?

The problem is on errors: implicit behavior makes error recovery harder.

> I could add that perhaps sometimes you don't know the kind of stream.

Can you give me a real life example of such a stream? just curious

>>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.

In my eyes, anything that the sitemap does implicitly is a potential
source of user misunderstanding and hard error recovery. This is based
on a *direct* experience, and I think I have enough cocoon knowledge to
go around problems.

> 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.

I'm currently in favor of this, generation should be explicit.

> *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.

If you really need that fuctionality, I would be in favor of introducing
an AdaptingURLGenerator that has the ability to deal with mime-types to
recognize the stream and parse then accordingly. This will keep your
functionality without moving its semantics into the sitemap.

> 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.

I disagree. I believe it's much more user friendly to have deal
*coherently* with the URI space. Equating verbosity with user
unfriendly-ness is, IMO, a pretty bad equation.

>>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. 

Look: I found it a barrier to include an .html file (which was valid
XHTML!) and see a JTidy-non-found error? where did that error come from?
I'm not using JTidy anywhere in my sitemap!

*this* took me half an hour to find out. It would have taken me a few
seconds to cut/paste a pipeline to deal with adapting HTML content if I
really wanted to.

(besides: how do you know the mime-type of a file on disk before
parsing? don't tell me you match extensions!)

> 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.

I can tell you want *I* want: coherence and explicitness in the sitemap.
Verbosity comes in second place.

> 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.

+1 to remove it.

other votes?


View raw message