You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/04/22 10:38:07 UTC
[Bug] default reader depends on JTidy!!!
I found out that the default reader uses the source resolver, which uses
an XMLizer, which uses JTidy if the resource extension is HTML.
Note that people previously didn't notice becuase the build was not
modularized but now that I install only the blocks I know my setup
depends on, I find it annoying that I can't serve HTML files straight
from disk.
Not counting the huge overhead that jtidy imposes when I just want to
read that file from disk without processing it.
Admittedly, cocoon should not be reading HTML files from disk directly
(the webserver should be doing it), but it's nice to do it locally and
then setup the proxypass configurations to optimize those servings on
production.
The workaround is to change the extension of the HTML file on disk to
something else.
I'm perfectly aware this is a bug in Excalibur XMLutils, but since it's
mainly our code and cocoon developers maintain it, I thought about
bringing it up here.
comments? (Sylvain, Carsten, anyone?)
--
Stefano.
Re: [Bug] default reader depends on JTidy!!!
Posted by Berin Loritsch <bl...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Berin Loritsch wrote, On 22/04/2003 14.05:
>
>> Stefano Mazzocchi wrote:
>>
>>>
>>> I'm perfectly aware this is a bug in Excalibur XMLutils, but since it's
>>> mainly our code and cocoon developers maintain it, I thought about
>>> bringing it up here.
>>>
>>> comments? (Sylvain, Carsten, anyone?)
>>
>>
>> Bringing up a good point. If XMLUtils is largely only a Cocoon
>> component, it probably should be maintained here. You guys could to
>> a much better job of it than the Avalon team. It hasn't garnered
>> more developer support other than Cocooners.
>
>
> And change the package name again? No way.
>
> Why can't Cocoon developers be granted karma upon request to
> avalon-excalibur?
You don't have to change the package name.
Right now, we are getting to a stable setup...
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
Re: [Bug] default reader depends on JTidy!!!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote, On 22/04/2003 14.05:
> Stefano Mazzocchi wrote:
>
>>
>> I'm perfectly aware this is a bug in Excalibur XMLutils, but since it's
>> mainly our code and cocoon developers maintain it, I thought about
>> bringing it up here.
>>
>> comments? (Sylvain, Carsten, anyone?)
>
> Bringing up a good point. If XMLUtils is largely only a Cocoon
> component, it probably should be maintained here. You guys could to
> a much better job of it than the Avalon team. It hasn't garnered
> more developer support other than Cocooners.
And change the package name again? No way.
Why can't Cocoon developers be granted karma upon request to
avalon-excalibur?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [Bug] default reader depends on JTidy!!!
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/22/03 5:35 PM Peter Royal wrote:
> Its hard to gauge usage on software pieces that work as advertised,
> because you don't have people asking support questions :)
Very true.
--
Stefano.
Re: [Bug] default reader depends on JTidy!!!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Steven Noels wrote, On 23/04/2003 8.49:
> On 23/04/2003 8:22 Nicola Ken Barozzi wrote:
>
>> On this I agree with you. We have indeed decided *not* to follow a
>> "Grand Component Repository Scheme", heading instead for a more
>> pragmatic solution. In fact all project-specific components remain
>> with the projects, and all utility code goes in other places. What
>> remains are common components, and keeping there in Avalon with common
>> access is IMHO the most sensible and easy thing to do to foster
>> cooperation with Avalon, that has instead always been seen as an ivory
>> tower.
>
> Cool. It's not my particular business, but I always thought Avalon is
> better at defining & implementing Component lifecycle management
> interfaces & containers rather than utility code, but it seems like
> reality is proving me wrong.
These are not generic utility code, these are Avalon Components.
Java utility code is being moved away, and mainly already has, along
with apps.
These are *shared* components, and that is why we need to open access to
other projects. It is not a place where Avaloners make components, but a
place *in* Avalon, where multiple projects cooperate on common
components. This helps us have a better relationship with our
"customers". Projects without users are generally of no use.
> Thanks for the patient explanation.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [Bug] default reader depends on JTidy!!!
Posted by Steven Noels <st...@outerthought.org>.
On 23/04/2003 8:22 Nicola Ken Barozzi wrote:
> On this I agree with you. We have indeed decided *not* to follow a
> "Grand Component Repository Scheme", heading instead for a more
> pragmatic solution. In fact all project-specific components remain with
> the projects, and all utility code goes in other places. What remains
> are common components, and keeping there in Avalon with common access is
> IMHO the most sensible and easy thing to do to foster cooperation with
> Avalon, that has instead always been seen as an ivory tower.
Cool. It's not my particular business, but I always thought Avalon is
better at defining & implementing Component lifecycle management
interfaces & containers rather than utility code, but it seems like
reality is proving me wrong.
Thanks for the patient explanation.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [Bug] default reader depends on JTidy!!!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Steven Noels wrote, On 22/04/2003 21.23:
...
> I just didn't like all this to be fitting into some Grand Component
> Repository Scheme, that's all.
On this I agree with you. We have indeed decided *not* to follow a
"Grand Component Repository Scheme", heading instead for a more
pragmatic solution. In fact all project-specific components remain with
the projects, and all utility code goes in other places. What remains
are common components, and keeping there in Avalon with common access is
IMHO the most sensible and easy thing to do to foster cooperation with
Avalon, that has instead always been seen as an ivory tower.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [Bug] default reader depends on JTidy!!!
Posted by Steven Noels <st...@outerthought.org>.
On 22/04/2003 21:27 Berin Loritsch wrote:
> Steven Noels wrote:
>> Anyway, as I don't see point in keeping them there, I don't see the
>> point in moving them neither - so giving Cocoon committers
>> karma-on-call seems like a pragmatic solution to me.
>>
>> I just didn't like all this to be fitting into some Grand Component
>> Repository Scheme, that's all.
>
>
> I put in a vote on Avalon Dev to grant Excalibur/Scratchpad access to
> Cocoon and JAMEs developers. That way, ALL who use those components
> can maintain them.
I saw that mail before replying, thank you for that!
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [Bug] default reader depends on JTidy!!!
Posted by Berin Loritsch <bl...@apache.org>.
Steven Noels wrote:
> On 22/04/2003 17:35 Peter Royal wrote:
>
>> They are. I use the XMLUtil components that are in avalon-excalibur
>> independently of Cocoon (Namely the parsers and xslt components).
>
>
> I stand corrected, then. XMLUtil _is_ used outside Cocoon, but I doubt
> whether that would not be the case if these classes were stored in some
> util package inside Cocoon... (see below)
>
>> Its hard to gauge usage on software pieces that work as advertised,
>> because you don't have people asking support questions :)
>
>
> I hardly believe someone with your credentials counts like normal
> 'people', Peter: you _are_ a Cocoon/Avalon committer, so either way you
> would know about their existence, and would know how to fix them without
> much fuzz if they didn't work for you ;-)
>
> Anyway, as I don't see point in keeping them there, I don't see the
> point in moving them neither - so giving Cocoon committers karma-on-call
> seems like a pragmatic solution to me.
>
> I just didn't like all this to be fitting into some Grand Component
> Repository Scheme, that's all.
I put in a vote on Avalon Dev to grant Excalibur/Scratchpad access to
Cocoon and JAMEs developers. That way, ALL who use those components
can maintain them.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
Re: [Bug] default reader depends on JTidy!!!
Posted by Steven Noels <st...@outerthought.org>.
On 22/04/2003 17:35 Peter Royal wrote:
> They are. I use the XMLUtil components that are in avalon-excalibur
> independently of Cocoon (Namely the parsers and xslt components).
I stand corrected, then. XMLUtil _is_ used outside Cocoon, but I doubt
whether that would not be the case if these classes were stored in some
util package inside Cocoon... (see below)
> Its hard to gauge usage on software pieces that work as advertised,
> because you don't have people asking support questions :)
I hardly believe someone with your credentials counts like normal
'people', Peter: you _are_ a Cocoon/Avalon committer, so either way you
would know about their existence, and would know how to fix them without
much fuzz if they didn't work for you ;-)
Anyway, as I don't see point in keeping them there, I don't see the
point in moving them neither - so giving Cocoon committers karma-on-call
seems like a pragmatic solution to me.
I just didn't like all this to be fitting into some Grand Component
Repository Scheme, that's all.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [Bug] default reader depends on JTidy!!!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Royal wrote, On 22/04/2003 17.35:
> On Tuesday, April 22, 2003, at 11:13 AM, Steven Noels wrote:
>
>>> I wanted to move all Avalon components to a common repository like
>>> Apache Commons where all projects could partecipate. Then we decided
>>> to keep it at Avalon. Then each project should keep their own but
>>> Avaloners would still keep common ones. Now we don't do this anymore
>>> and Avalon will not have a Component repository.
>>> A Component Repository with just access to Avalon developers is d*e*a*d.
>>
>>
>> Sure. I believe reality is explaining you here that this Component
>> repository isn't bound to happen, or at least that the 'Cocoon-related
>> Components' inside that repository have not proven to be of much
>> interest to others, IIUC.
>
> They are. I use the XMLUtil components that are in avalon-excalibur
> independently of Cocoon (Namely the parsers and xslt components).
Same with FOP soon BTW.
> Its hard to gauge usage on software pieces that work as advertised,
> because you don't have people asking support questions :)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [Bug] default reader depends on JTidy!!!
Posted by Peter Royal <pr...@apache.org>.
On Tuesday, April 22, 2003, at 11:13 AM, Steven Noels wrote:
>> I wanted to move all Avalon components to a common repository like
>> Apache Commons where all projects could partecipate. Then we decided
>> to keep it at Avalon. Then each project should keep their own but
>> Avaloners would still keep common ones. Now we don't do this anymore
>> and Avalon will not have a Component repository.
>> A Component Repository with just access to Avalon developers is
>> d*e*a*d.
>
> Sure. I believe reality is explaining you here that this Component
> repository isn't bound to happen, or at least that the 'Cocoon-related
> Components' inside that repository have not proven to be of much
> interest to others, IIUC.
They are. I use the XMLUtil components that are in avalon-excalibur
independently of Cocoon (Namely the parsers and xslt components).
Its hard to gauge usage on software pieces that work as advertised,
because you don't have people asking support questions :)
-pete
Re: [Bug] default reader depends on JTidy!!!
Posted by Steven Noels <st...@outerthought.org>.
On 22/04/2003 15:55 Nicola Ken Barozzi wrote:
> Steven Noels wrote, On 22/04/2003 15.49:
>
>> On 22/04/2003 14:05 Berin Loritsch wrote:
>>
>>> Bringing up a good point. If XMLUtils is largely only a Cocoon
>>> component, it probably should be maintained here. You guys could to
>>> a much better job of it than the Avalon team. It hasn't garnered
>>> more developer support other than Cocooners.
>>
>>
>> Right on.
>
>
> I just hate it when things keep getting moved from one place to the
> other, when there is no real need, since Cocoon developers can be
> granted access there.
Then why are there 2 different projects? :-)
> I wanted to move all Avalon components to a common repository like
> Apache Commons where all projects could partecipate. Then we decided to
> keep it at Avalon. Then each project should keep their own but Avaloners
> would still keep common ones. Now we don't do this anymore and Avalon
> will not have a Component repository.
>
> A Component Repository with just access to Avalon developers is d*e*a*d.
Sure. I believe reality is explaining you here that this Component
repository isn't bound to happen, or at least that the 'Cocoon-related
Components' inside that repository have not proven to be of much
interest to others, IIUC.
> If we keep excalibur, we must grant access to others. Else we just kill
> it. All of it.
If no-one but a few cares, why not?
> Other than that, I have nothing more to say, here at work it's hell and
> I'm mad as I can be. Sorry if I seem harsh, this is the best I can do
> not to be so. Thanx
It's appreciated, Nicola. :-)
I really think you are trying too hard - and I admire you for doing so.
But when reality tells us otherwise, we should listen, since I would
loath to see you running around frustrated.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [Bug] default reader depends on JTidy!!!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Steven Noels wrote, On 22/04/2003 15.49:
> On 22/04/2003 14:05 Berin Loritsch wrote:
>
>> Bringing up a good point. If XMLUtils is largely only a Cocoon
>> component, it probably should be maintained here. You guys could to
>> a much better job of it than the Avalon team. It hasn't garnered
>> more developer support other than Cocooners.
>
> Right on.
I just hate it when things keep getting moved from one place to the
other, when there is no real need, since Cocoon developers can be
granted access there.
I wanted to move all Avalon components to a common repository like
Apache Commons where all projects could partecipate. Then we decided to
keep it at Avalon. Then each project should keep their own but Avaloners
would still keep common ones. Now we don't do this anymore and Avalon
will not have a Component repository.
A Component Repository with just access to Avalon developers is d*e*a*d.
If we keep excalibur, we must grant access to others. Else we just kill
it. All of it.
Other than that, I have nothing more to say, here at work it's hell and
I'm mad as I can be. Sorry if I seem harsh, this is the best I can do
not to be so. Thanx
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [Bug] default reader depends on JTidy!!!
Posted by Steven Noels <st...@outerthought.org>.
On 22/04/2003 14:05 Berin Loritsch wrote:
> Bringing up a good point. If XMLUtils is largely only a Cocoon
> component, it probably should be maintained here. You guys could to
> a much better job of it than the Avalon team. It hasn't garnered
> more developer support other than Cocooners.
Right on.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [Bug] default reader depends on JTidy!!!
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
>
> I'm perfectly aware this is a bug in Excalibur XMLutils, but since it's
> mainly our code and cocoon developers maintain it, I thought about
> bringing it up here.
>
> comments? (Sylvain, Carsten, anyone?)
Bringing up a good point. If XMLUtils is largely only a Cocoon
component, it probably should be maintained here. You guys could to
a much better job of it than the Avalon team. It hasn't garnered
more developer support other than Cocooners.
What are your thoughts?
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
Re: [Bug] default reader depends on JTidy!!!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 22/04/2003 10.38:
> I found out that the default reader uses the source resolver, which uses
> an XMLizer, which uses JTidy if the resource extension is HTML.
Aaaargggh! :-/
Nice catch, terrible bug.
...
> I'm perfectly aware this is a bug in Excalibur XMLutils, but since it's
> mainly our code and cocoon developers maintain it, I thought about
> bringing it up here.
>
> comments? (Sylvain, Carsten, anyone?)
This is really nasty, and brings up the issue with the XMLizer. If a
shource is XML, it *may* make sense to use the XMLizer, else it's
totally off-target.
Aslo, let's say that I want to get a stream to an xml file that I want
to zip... will the sourceresolver *parse* it just to give it to me?
There is something wrong here...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: XMLForm & JavaScript incompatibility
Posted by Konstantin Piroumian <kp...@apache.org>.
Use this:
document.forms[0].elements["/root/field"];
or this (if you set the 'id' attribute):
document.getElementById("/root/field");
--
Konstantin
From: "Yatin Shah" <no...@kripa.com>
> JavaScript incompatibility results when using
> XMLForm with a xf:group option or when the
> ref argument refers to a name containing the slash character('/').
>
> This becomes an issue if one desires to use javascript features
> to access and manipulate the state of input fields.
> In the example below, '/activityForm/DBdata/startDate' is an
> invalid JavaScript name.[Although, it's a proper jxpath name!]
>
> Apurva zaveri [1] had a similar issue. Does anyone know
> how to get around this problem?
>
>
> SAMPLE XMLFORM code
> -------------------
>
> <xf:group ref="/activityForm/DBdata">
> <xf:textbox ref="startTime">
> <xf:caption>Start Time</xf:caption>
> <xf:violations class="error"/>
> </xf:textbox>
> </xf:group>
>
> Resulting HTML
> --------------
>
> <input name="/activityForm/DBdata/startDate" type="textbox"
value="2002-09-23">
>
>
> [1]:
http://marc.theaimsgroup.com/?l=xml-cocoon-users&w=2&r=1&s=xmlform+JavaScrip
t&q=b
>
>
> --
> Yatin Shah, President mailto:ygs@kripa.com
> Kripa Inc. http://www.kripa.com
> Dayton, New Jersey USA phone: 732.329.8303
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Developers of real time event driven distributed DB application
>
>
>
Re: XMLForm & JavaScript incompatibility
Posted by ivelin <iv...@apache.org>.
Would it not work if you use the alternative JS syntax
form.field['/activityForm/DBdata/startDate'].value = "10/03/2003"
-=Ivelin=-
----- Original Message -----
From: "Yatin Shah" <no...@kripa.com>
To: <co...@xml.apache.org>
Sent: Tuesday, April 22, 2003 4:46 PM
Subject: XMLForm & JavaScript incompatibility
> JavaScript incompatibility results when using
> XMLForm with a xf:group option or when the
> ref argument refers to a name containing the slash character('/').
>
> This becomes an issue if one desires to use javascript features
> to access and manipulate the state of input fields.
> In the example below, '/activityForm/DBdata/startDate' is an
> invalid JavaScript name.[Although, it's a proper jxpath name!]
>
> Apurva zaveri [1] had a similar issue. Does anyone know
> how to get around this problem?
>
>
> SAMPLE XMLFORM code
> -------------------
>
> <xf:group ref="/activityForm/DBdata">
> <xf:textbox ref="startTime">
> <xf:caption>Start Time</xf:caption>
> <xf:violations class="error"/>
> </xf:textbox>
> </xf:group>
>
> Resulting HTML
> --------------
>
> <input name="/activityForm/DBdata/startDate" type="textbox"
value="2002-09-23">
>
>
> [1]:
http://marc.theaimsgroup.com/?l=xml-cocoon-users&w=2&r=1&s=xmlform+JavaScrip
t&q=b
>
>
> --
> Yatin Shah, President mailto:ygs@kripa.com
> Kripa Inc. http://www.kripa.com
> Dayton, New Jersey USA phone: 732.329.8303
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Developers of real time event driven distributed DB application
>
XMLForm & JavaScript incompatibility
Posted by Yatin Shah <no...@kripa.com>.
JavaScript incompatibility results when using
XMLForm with a xf:group option or when the
ref argument refers to a name containing the slash character('/').
This becomes an issue if one desires to use javascript features
to access and manipulate the state of input fields.
In the example below, '/activityForm/DBdata/startDate' is an
invalid JavaScript name.[Although, it's a proper jxpath name!]
Apurva zaveri [1] had a similar issue. Does anyone know
how to get around this problem?
SAMPLE XMLFORM code
-------------------
<xf:group ref="/activityForm/DBdata">
<xf:textbox ref="startTime">
<xf:caption>Start Time</xf:caption>
<xf:violations class="error"/>
</xf:textbox>
</xf:group>
Resulting HTML
--------------
<input name="/activityForm/DBdata/startDate" type="textbox" value="2002-09-23">
[1]: http://marc.theaimsgroup.com/?l=xml-cocoon-users&w=2&r=1&s=xmlform+JavaScript&q=b
--
Yatin Shah, President mailto:ygs@kripa.com
Kripa Inc. http://www.kripa.com
Dayton, New Jersey USA phone: 732.329.8303
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Developers of real time event driven distributed DB application
Re: [Bug] default reader depends on JTidy!!!
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/22/03 2:20 PM Peter Royal wrote:
> So for your example of HTML files, in order to successfully convert
> them into valid XML, JTidy is used. If you just want to serve static
> HTML, you probably want to use a reader, and not a generator.
I *AM* using a reader! That's the point.
--
Stefano.
Re: [Bug] default reader depends on JTidy!!!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote, On 22/04/2003 14.34:
> Peter Royal wrote:
...
>> Correct me if I'm wrong here, but I believe the XMLizer only kicks in
>> if you want to call toSAX on a source. (or if a source is not XMLizable)
>>
>> So for your example of HTML files, in order to successfully convert
>> them into valid XML, JTidy is used. If you just want to serve static
>> HTML, you probably want to use a reader, and not a generator.
>> -pete
>
> I think the problem is that the XMLIzer is used even when the HTML is
> called by a Reader.
Ok, then we have a bug, not a design problem.
The contract (at least the contract I suppose would be the right one) is
that the least-expensive route is taken, given the requested output.
I would not remove the XMLizable stuff, because if the source is XML,
and I ask it as XML, I would not want to be transformed to a stream. I
would have the problem backwards in this case.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [Bug] default reader depends on JTidy!!!
Posted by Berin Loritsch <bl...@apache.org>.
Peter Royal wrote:
> On Tuesday, April 22, 2003, at 07:37 AM, Stefano Mazzocchi wrote:
>
>> In this case, transparent XMLizing is *very bad* because it is hidden
>> underneath *TONS* of code and nobody will ever find out (I personally
>> found out because of the missing class, otherwise, I would not have
>> noticed)
>>
>> the source resolver should not try to outsmart its users. If i ask for a
>> stream of chars, give me what I ask for nothing more nothing less.
>
>
> Correct me if I'm wrong here, but I believe the XMLizer only kicks in if
> you want to call toSAX on a source. (or if a source is not XMLizable)
>
> So for your example of HTML files, in order to successfully convert them
> into valid XML, JTidy is used. If you just want to serve static HTML,
> you probably want to use a reader, and not a generator.
> -pete
I think the problem is that the XMLIzer is used even when the HTML is
called by a Reader.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
Re: [Bug] default reader depends on JTidy!!!
Posted by Peter Royal <pr...@apache.org>.
On Tuesday, April 22, 2003, at 07:37 AM, Stefano Mazzocchi wrote:
> In this case, transparent XMLizing is *very bad* because it is hidden
> underneath *TONS* of code and nobody will ever find out (I personally
> found out because of the missing class, otherwise, I would not have
> noticed)
>
> the source resolver should not try to outsmart its users. If i ask for
> a
> stream of chars, give me what I ask for nothing more nothing less.
Correct me if I'm wrong here, but I believe the XMLizer only kicks in
if you want to call toSAX on a source. (or if a source is not XMLizable)
So for your example of HTML files, in order to successfully convert
them into valid XML, JTidy is used. If you just want to serve static
HTML, you probably want to use a reader, and not a generator.
-pete
Re: [Bug] default reader depends on JTidy!!!
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/22/03 10:54 AM Stephan Michels wrote:
> I think the concept of the XMLizer failed, because it's obsolete. If
> you are writing a 'xmlizer' for our own format, you will almost
> write a generator.
Exactly!
> And you doesn't have a mime-type mapping everywhere.
> For example the mime-type mapping doesn't work in the CLI.
> At moment if you use Cocoon in a servlet environment, JTidy is used
> for *.html, but in the CLI the default 'xmlizer' is used.
>
> I think you should avoid that by removing the xmlizer concept. We do have
> several genertor for the different formats.
>
> <generator type="file" src="{1}.xml"/>
> <generator type="html" src="{1}.html"/>
>
> What do you think?
I think everything that happens transparently is actually happening
behind my back and I want to know about it.
In this case, transparent XMLizing is *very bad* because it is hidden
underneath *TONS* of code and nobody will ever find out (I personally
found out because of the missing class, otherwise, I would not have noticed)
the source resolver should not try to outsmart its users. If i ask for a
stream of chars, give me what I ask for nothing more nothing less.
--
Stefano.
Re: [Bug] default reader depends on JTidy!!!
Posted by Stephan Michels <st...@apache.org>.
On Tue, 22 Apr 2003, Stefano Mazzocchi wrote:
> I found out that the default reader uses the source resolver, which uses
> an XMLizer, which uses JTidy if the resource extension is HTML.
>
> Note that people previously didn't notice becuase the build was not
> modularized but now that I install only the blocks I know my setup
> depends on, I find it annoying that I can't serve HTML files straight
> from disk.
>
> Not counting the huge overhead that jtidy imposes when I just want to
> read that file from disk without processing it.
>
> Admittedly, cocoon should not be reading HTML files from disk directly
> (the webserver should be doing it), but it's nice to do it locally and
> then setup the proxypass configurations to optimize those servings on
> production.
>
> The workaround is to change the extension of the HTML file on disk to
> something else.
I think the concept of the XMLizer failed, because it's obsolete. If
you are writing a 'xmlizer' for our own format, you will almost
write a generator. And you doesn't have a mime-type mapping everywhere.
For example the mime-type mapping doesn't work in the CLI.
At moment if you use Cocoon in a servlet environment, JTidy is used
for *.html, but in the CLI the default 'xmlizer' is used.
I think you should avoid that by removing the xmlizer concept. We do have
several genertor for the different formats.
<generator type="file" src="{1}.xml"/>
<generator type="html" src="{1}.html"/>
What do you think?
Re: [Bug] default reader depends on JTidy!!!
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le mardi, 22 avr 2003, à 10:38 Europe/Zurich, Stefano Mazzocchi a écrit
:
> I found out that the default reader uses the source resolver, which
> uses
> an XMLizer, which uses JTidy if the resource extension is HTML....
XMLizer can be confusing IMHO - for example, the Chaperon block uses it
to automagically parse .txt files, but this is not visible in the
sitemap as it happens behind the scenes. Took me a while to find out
why parsing txt files worked without me saying anything in the sitemap
(and why it stopped working if I renamed my .txt files to .wiki).
Is there an easy way to disable XMLizing by configuration?
If so, maybe it should be disabled by default to avoid confusion?
I don't know all the issues but too much automagic stuff is often
confusing.
-Bertrand