You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by "Peter B. West" <pb...@powerup.com.au> on 2002/12/15 06:38:51 UTC
Including legacy html
Forrest-devs,
Is it possible to include legacy html in a forrest-generated site? I
cannot see a way, so I would appreaciate some advice. My particular
requirement is to be able to include XE/e/macs htmlized code, or
fragments thereof, in generated code. The ideal would be to be able to
insert chunks directly in the generated pages, but I realise that this
is probably asking too much. As a fall-back, the ability to correctly
refer to complete html pages in, say <jump/> elements would suffice. I
am thinking of having such pages, or subtrees of pages, in the resources
directory under src/documentation.
I doubt that I am the only one who will need to accommodate legacy html.
The attempts I have made include hacking the build.xml to copy html
subdirs into the context directory, have failed. because the link
resolution fails and I get an error page in place of the original.
Is there some Q&D way to do this?
Peter
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
Re: Including legacy html
Posted by Jeff Turner <je...@apache.org>.
On Sun, Dec 15, 2002 at 06:43:01PM -0500, Rodent of Unusual Size wrote:
> Steven Noels wrote:
> >
> > Seriously: while I see some value in this verbatim inclusion of
> > external, non-XML fragments, I don't see much value in conditional
> > behaviour. It's the kind of stuff which gets thrown back in your face, IMHO.
>
> i find this position contradictory given the recent discussion
> about presentation versus semantics. some people are going
> to want .. no, *need* to take control over some presentation-level
> aspects. you've already gone on record as saying you don't think
> that should go into the general markup; how can i interpret
> your quoted remark above as anything other than an opinion that
> content-developers/forrest-users should have no control over presentation
> whatsoever? maybe i'm seeing things in too few shades of grey.
>
> for example: one external fragment may be appropriate if the target
> format is equation-capable, like *roff; another is better for
> html; still a third is better for audio presentation for the
> blind. please don't assume that a) the transformation stylesheets
> are going to make the best choices in these cases, nor that b) the
> contenr-developers have the least idea or desire to frob the
> stylesheets.
>
> give 'em rope.
I think we should:
- first work out how to solve the problem
- THEN worry about whether the solution ends up in Forrest's core.
We could establish a contrib/ directory for non-mainstream setups. I
have a few to contribute.
Soo..
There were two separate proposals on this thread:
a) A mechanism for including raw content in the output:
<pre>
<include-verbatim src="sample.raw"/>
</pre>
If sample.raw is XML, I'd use the XIncludeTransformer. If it isn't, I'd
use an entity:
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN"
"document-v11.dtd" [
<!ENTITY raw-content SYSTEM "sample.raw">
]>
<document>
...
<p xml:space="preserve">
&raw-content;
</p>
...
</document>
Non-XML characters in sample.raw can be escaped with <![CDATA[&raw-content;]]>
Would that solve the problem?
b) Conditional inclusion of a section depending on output type:
<if target="html"> .. </if>
Seems fairly straightforward to add to the DTD, and exclude from the
copy-everything template in the stylesheet. I can make an example if you like.
To become part of Forrest would require some solid use-cases though.
--Jeff
Re: Including legacy html
Posted by Steven Noels <st...@outerthought.org>.
Rodent of Unusual Size wrote:
> Steven Noels wrote:
>
>>Seriously: while I see some value in this verbatim inclusion of
>>external, non-XML fragments, I don't see much value in conditional
>>behaviour. It's the kind of stuff which gets thrown back in your face, IMHO.
>
>
> i find this position contradictory given the recent discussion
> about presentation versus semantics. some people are going
> to want .. no, *need* to take control over some presentation-level
> aspects. you've already gone on record as saying you don't think
> that should go into the general markup; how can i interpret
> your quoted remark above as anything other than an opinion that
> content-developers/forrest-users should have no control over presentation
> whatsoever? maybe i'm seeing things in too few shades of grey.
Maybe. Or my opinion changes due to progressive learning.
> for example: one external fragment may be appropriate if the target
> format is equation-capable, like *roff; another is better for
> html; still a third is better for audio presentation for the
> blind. please don't assume that a) the transformation stylesheets
> are going to make the best choices in these cases, nor that b) the
> contenr-developers have the least idea or desire to frob the
> stylesheets.
So what do you propose here? Have some element/attribute which tells iin
what rendition form the content of that element should be processed.
More like a filter:
<verbatim src="foobar.nroff" target="html"/>
will not be shown in xsl-fo/pdf output. Is it that what you are looking for?
Also, bear in mind that such inlined non-XML fragments will likely be
wrapped as an OBJECT element in HTML, and a fo:external-graphic thing in
XSL-FO, which the stylesheet needs to infer anyhow. So it's both the
document _and_ the stylesheet author at work at the same time.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: Including legacy html
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Steven Noels wrote:
>
> Seriously: while I see some value in this verbatim inclusion of
> external, non-XML fragments, I don't see much value in conditional
> behaviour. It's the kind of stuff which gets thrown back in your face, IMHO.
i find this position contradictory given the recent discussion
about presentation versus semantics. some people are going
to want .. no, *need* to take control over some presentation-level
aspects. you've already gone on record as saying you don't think
that should go into the general markup; how can i interpret
your quoted remark above as anything other than an opinion that
content-developers/forrest-users should have no control over presentation
whatsoever? maybe i'm seeing things in too few shades of grey.
for example: one external fragment may be appropriate if the target
format is equation-capable, like *roff; another is better for
html; still a third is better for audio presentation for the
blind. please don't assume that a) the transformation stylesheets
are going to make the best choices in these cases, nor that b) the
contenr-developers have the least idea or desire to frob the
stylesheets.
give 'em rope.
Re: Including legacy html
Posted by Steven Noels <st...@outerthought.org>.
Rodent of Unusual Size wrote:
> Steven Noels wrote:
>
>>>does forrest support any sort of conditional-on-output mechanism?
>>>like <if target="html"> .. </if>?
>>
>>Nope. This is hidden in the sitemap/stylesheets.
>
>
> is there no hope for it appearing at a higher level where real users
> (not x*-savvy developers) might take advantage of it?
We must ask the project manager :)
Seriously: while I see some value in this verbatim inclusion of
external, non-XML fragments, I don't see much value in conditional
behaviour. It's the kind of stuff which gets thrown back in your face, IMHO.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: Including legacy html
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Steven Noels wrote:
>
> > does forrest support any sort of conditional-on-output mechanism?
> > like <if target="html"> .. </if>?
>
> Nope. This is hidden in the sitemap/stylesheets.
is there no hope for it appearing at a higher level where real users
(not x*-savvy developers) might take advantage of it?
Re: Including legacy html
Posted by Steven Noels <st...@outerthought.org>.
Rodent of Unusual Size wrote:
> Steven Noels wrote:
>
>>Would characters in the inserted non-XML fragment need to be escaped
>>upon rendition - < & ... ?
which means you won't use them for source code samples if I'm correct:
in Moz1.2, the following sample only shows the letter 'A':
<html>
<head>
<title>foobar</title>
</head>
<body>
<pre>A<b
1&2=3</pre>
</body>
</html>
> on my first pass, i'd say 'no'. this is a moderately advanced operation;
> anyone using it should bear the responsibility of making the inclusion
> safe. for future work, having an option to do it either way would
> be excellent rope to braid.
If this is for including possibly unsafe content, I would make escaping
part of the system instead of putting in the hands of the user. I see
Eliotte makes use of XInclude for that purpose - look at the source of
http://www.cafeconleche.org/slides/sd2002east/xmlfundamentals/08.html
> does forrest support any sort of conditional-on-output mechanism?
> like <if target="html"> .. </if>?
Nope. This is hidden in the sitemap/stylesheets.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: Including legacy html
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Steven Noels wrote:
>
> Would characters in the inserted non-XML fragment need to be escaped
> upon rendition - < & ... ?
on my first pass, i'd say 'no'. this is a moderately advanced operation;
anyone using it should bear the responsibility of making the inclusion
safe. for future work, having an option to do it either way would
be excellent rope to braid.
does forrest support any sort of conditional-on-output mechanism?
like <if target="html"> .. </if>?
Re: Including legacy html
Posted by Steven Noels <st...@outerthought.org>.
Rodent of Unusual Size wrote:
> as far as that goes, is there any reason the dtd can't support an element
> that's meaningless except to the transformer, and executed non-recursively
> during transformation? something like:
>
> <pre>
> <include-verbatim src="sample.raw"/>
> </pre>
>
Would characters in the inserted non-XML fragment need to be escaped
upon rendition - < & ... ? Is this to show sourcecode fragments
as you indicate in your example with the <pre> tags or to inject
in-place verbatim HTML...?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: Including legacy html
Posted by Steven Noels <st...@outerthought.org>.
Rodent of Unusual Size wrote:
> i think we're not communicating. stylesheet instructions are in xml.
> what they *act on* does not need to be, does it?
XSL stylesheets _require_ a well-formed XML input tree. It also
_prefers_ well-formed XML output - just take a look at the Gump
stylesheets generating shell scripts to see what happens if you try to
generate non-XML output.
Anakia will always be more flexible since it has no standard to implement.
> i'm talking about
> an instruction 'include this external thing verbatim on the output
> side of the loop; don't try to do anything with it, it isn't for
> you. just include the frickin' thing right here in the output.'
I will play around with this idea some more. For source fragments, it
isn't a bad idea. To inject HTML in the output, I don't know.
> forrest can be as fast or as slow as it takes. is the primary goal
> do a little really fast, or do a lot in whatever time it takes?
Do a lot & do it right.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: Including legacy html
Posted by David Crossley <cr...@indexgeo.com.au>.
Andrew C. Oliver wrote:
<snip/>
> The fourth choice:
>
> - convince others that it is a problem, build a consensus and drive
> action towards that effect. You keep telling me love it or leave it.
> Maybe one day I'll leave it Stefano. I haven't given up yet. I just
> have a lot of stuff to sort through before I can do it myself.
You have not done much convincing yet Andy. All that you
seem to do is blow in to this list, complain about this
and that, then leave again.
Stefano continued:
> > Con Forrest be faster than Anakia? hardly. Anakia doesn't even parse
> > the XML. It's a text generation system. It's designed for command
> > line. It's designed for unstructured data. It's designed for small
> > sites. It's designed with no idea of SoC.
>
> Okay this is the practitioner versus the achedemic here. I don't care
> about SoC if SoC means my docs come out in 10 minutes versus 1.
Well if you do not care about separation of concerns, then
i think that Forrest and Cocoon are not meant for you.
> > In short, they are two different things that happen to have partial
> > functionality overlap.
>
> Exactly what practical thing does forrest do that Anakia doesn't other
> than PDF generation?
Please, let us not squabble over whose product is better.
> > Andy, if you like Anakia more because it fits your needs, use that!
>
> I usually do. I hope one day not to have to.
>
> > And then complain to them about the fact that it doesn't this or that,
> > even if it *doesn't* very quickly :-P
> >
> Sorry to burn your holy books... But I just want it to work fast enough
> to use.
It is plenty fast enough for me. There are other more
pressing things for me to expend my Forrest time upon.
--David
Re: Including legacy html
Posted by Jeff Turner <je...@apache.org>.
On Wed, Dec 18, 2002 at 10:15:58PM -0500, Andrew C. Oliver wrote:
> >I'd say that whoever feels that forrest is talking more time than it
> >needed it has two choices:
> >
> > - get dirty with it and make it faster
>
>
> Don't know how.
>
> > - use something else
>
> I do in most cases.
>
> >
> >The third choice:
> >
> > - complaining about it without doing anything
>
> The fourth choice:
>
> - convince others that it is a problem, build a consensus and drive
> action towards that effect.
I think we need a userexperiences.xml page, describing what working with
Forrest is really like. I would write a long entry about how it feels
like cracking a nut with a sledgehammer.. simple things are hard, it's
overcomplicated, slow, large (13mb) and at the end of the day, the
advantages of using Forrest on a small site only barely outweigh the
disadvantages. Unless you've drunk the Cocoon kool-aid, Anakia is going
to be a better choice.
But then we'd also need a future.xml page, describing how Forrest has the
potential to be incredibly cool, and in fact already is on larger sites.
We need to get back to the original Forrest vision where the CLI was
purely a last-step serialization. Specifically, users should not need to
run the CLI to view the results of edits! 'forrest run' works today, but
isn't good enough, as docs must be edited in build/webapp. Then we need
to drastically simplify Forrest. Get the unused crud out of the default
sitemap (Konstantin's latest email looked very relevant), so we can stop
hiding the sitemap, and rather *encourage* users to poke around, and
discover how arbitrarily powerful the Cocoon architecture makes Forrest.
We need to unify the source directory structure. We need to make
content/presentation separation an obviously _worthwhile_ goal, not a
matter of dogma. Acme Widget Co should be able to add a <widget> tag in
minutes. We need user feedback modules, to demonstrate Forrest's unique
scalability: we can go from static to dynamic sites, with the same
architecture. All this before breakfast :)
--Jeff
Re: Including legacy html
Posted by Steven Noels <st...@outerthought.org>.
Andrew C. Oliver wrote:
> Okay. In that case, since the form of contribution that I'm able to
> give is not valuable, I will cease contributing to the project in this
> manner, cease evangelizing its use or tracking it.
I knew you were going to react in that way - still I thought it wasn't
necessary to add the usual disclaimer of my reply not being aimed
directly at you. Oh well - I should have known better.
My reply was a rant, a feeling and a constatation, not a critique. I
really think, also given the recent turbulence, that young and fledgling
projects can break under too much community pressure, which is exactly
what is happening to Forrest right now.
There are two ways to cope with interactions like yours and Kens:
a) try to patch and tweak Forrest in order to make it support each &
every wish every possible user could have, creating FS along the way
b) try to come up with a decent set of core features and explain what
we, in all modesty, think might be 'better' in the long run
To use another metaphore: imagine yourself trying really hard to be a
good father, and dr. Spock looking from behind your back pointing at
each little mistake you make along the way.
Please regard my reply as an invitation to be more involved instead of less.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: Including legacy html
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Okay. In that case, since the form of contribution that I'm able to
give is not valuable, I will cease contributing to the project in this
manner, cease evangelizing its use or tracking it.
-Andy
Steven Noels wrote:
> Andrew C. Oliver wrote:
>
>> The fourth choice:
>>
>> - convince others that it is a problem, build a consensus and drive
>> action towards that effect.
>
>
> This isn't a real option IMHO. Escaping from my Lab Rats [1] meme, I
> think the only real value one can contribute to a project is ...
> actual contribututions. Even worse, I start to believe that other
> things can be counterproductive, but I still need arguments to prove
> that point.
>
> It's like a relationship. You want some commitment, some strings
> attached. Otherwise you just go and buy some love.
>
> </Steven>
>
> [1] http://radio.weblogs.com/0103539/2002/12/03.html#a80
Re: Including legacy html
Posted by Steven Noels <st...@outerthought.org>.
Andrew C. Oliver wrote:
> The fourth choice:
>
> - convince others that it is a problem, build a consensus and drive
> action towards that effect.
This isn't a real option IMHO. Escaping from my Lab Rats [1] meme, I
think the only real value one can contribute to a project is ... actual
contribututions. Even worse, I start to believe that other things can be
counterproductive, but I still need arguments to prove that point.
It's like a relationship. You want some commitment, some strings
attached. Otherwise you just go and buy some love.
</Steven>
[1] http://radio.weblogs.com/0103539/2002/12/03.html#a80
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
[OT] Rant about bashing academia
Posted by Miles Elam <mi...@geekspeak.org>.
Andrew C. Oliver wrote:
> The fourth choice:
>
> - convince others that it is a problem, build a consensus and drive
> action towards that effect. You keep telling me love it or leave it.
> Maybe one day I'll leave it Stefano. I haven't given up yet. I just
> have a lot of stuff to sort through before I can do it myself.
Convince others that it is a problem? This statement carries the
implication that the developers do not currently know how long it
takes. It assumes that they have made the decision to completely ignore
speed. I find that hard to believe and frankly find it hard to believe
that you believe it too.
>> Can Forrest be faster than it is today? sure. I think that with
>> tweaking the sitemap and the component pools we can gain a lot of
>> speed. Also I'm not sure how 'cache friendly' the Cocoon CLI is (that
>> is another source of major speed gain).
>
> That is my concern. Its not that usable in many cases at its current
> speed.
Ever heard the quote "premature optimization is the root of all evil?"
You code for correctness first and then optimize. Doing the opposite is
a sure recipe for incorrect (and incorrectable) behavior.
>> Con Forrest be faster than Anakia? hardly. Anakia doesn't even parse
>> the XML. It's a text generation system. It's designed for command
>> line. It's designed for unstructured data. It's designed for small
>> sites. It's designed with no idea of SoC.
>
> Okay this is the practitioner versus the achedemic here. I don't care
> about SoC if SoC means my docs come out in 10 minutes versus 1.
Even if in the one minute case, the docs come out wrong? Even if in the
one minute case, maintainability suffers? People are lazy. Programmers
doubly so. If the design does not enforce the intent, the intent is lost.
Practitioners brought about browser feature-creep escalation and tag
soup that is the web today. Academic rigor brought us web standards.
If you want the practitioner approach, use Anakia. I assume that it
would serve you well. If you want something that works more with
context and clear guidelines of role in documentation generator, it
might benefit looking at how Forrest tries to solve the problem.
>> In short, they are two different things that happen to have partial
>> functionality overlap.
>
> Exactly what practical thing does forrest do that Anakia doesn't other
> than PDF generation?
SoC. Just because it holds no value in your opinion does not mean that
it holds no value.
>> Andy, if you like Anakia more because it fits your needs, use that!
>
> I usually do. I hope one day not to have to.
Why not? If SoC does not matter to you as much as speed, why on earth
would you want to use Forrest? What is it about Anakia that you find so
offensive that Forrest must be your saviour?
>> And then complain to them about the fact that it doesn't this or
>> that, even if it *doesn't* very quickly :-P
>
> Sorry to burn your holy books... But I just want it to work fast
> enough to use.
I hope everyone recognizes that these same comments were used to deride
Mozilla two years ago. Their first priority was to correctness. People
told them that they were crazy. They didn't care about "academic"
correctness; They wanted it fast *now*. They said the object model was
useless overhead. They said that if the program was slow now -- despite
repeated attempts to explain the utility of good interfaces and
processes before implementation optimizations -- it would always be
slow. I would like everyone to take a good look at the difference
between M16 and v1.2.1 of Mozilla.
I would like everyone to reflect on what Mozilla would be like if they
had gone for the quick speed fixes instead of concentrating on good,
maintainable (!!!) design first. Where would we be? I'll tell you
where we'd be. We'd have another semi-standards-complaint browser like
IE that made developers bend over backwards to get pages to work but
without the benefit of W3C standards pages to give sanity checks as to
what "correct behavior" was. We'd have another browser that worked on a
handful of platforms, but because of resource constraints, completely
ignore others. Unlike IE and Opera, the page I make on Linux renders
the same on Mac, Windows, Solaris, etc. iCab is plenty fast, but don't
expect standards out of it anytime soon. I would expect Mozilla to
speed up at a greater pace.
I don't know about you, but I want nothing to do with the days of
specifying both marginheight/marginwidth and leftmargin/topmargin,
spacer gifs, tables for layout, the blink tag, the font tag, the morass
of conflicting frames syntax, differing font sizes for Macs vs. PCs.
The practicioners aren't doing anything useful in this regard. It's the
academics who are trying to find a way out of this mess while the
practicioners bitch about all of the shit code they have to completely
rewrite because they had no design cycle.
Where would many Open Source projects be if the Mozilla group hadn't
spent the time to create Bugzilla in the early stages of their
development cycle? Tinderbox? Rhino?
Contrary to popular belief, good software takes a long time. How long
had Linux been around before it became a truly functional system? How
long has UNIX been around? How long has the Apache web server been
around, making fixes, adding features, etc.? And you want Forrest to do
everything planned right now, this minute, and with excellent performance?
I am afraid your expectations simply are not reasonable.
- Miles
P.S. I am 28 years old and do not have a degree. When I started
college ten years ago, I was a literature major. I am by no means some
stifled computer science academic who hasn't seen the real world and
business. What I have seen is project after project that was crushed
under its own weight because there wasn't sufficient discipline when the
project was started...because of speed (performance and time to release)
concerns. Silicon Valley is littered with the corpses of companies full
of practicioners. One of the saving graces of Open Source is the
liberty to spend the time to get it right.
"Is the Dark Side stronger?"
"No! Quicker. Easier. More seductive."
Re: Including legacy html
Posted by "Andrew C. Oliver" <ac...@apache.org>.
> I'd say that whoever feels that forrest is talking more time than it
> needed it has two choices:
>
> - get dirty with it and make it faster
Don't know how.
> - use something else
I do in most cases.
>
> The third choice:
>
> - complaining about it without doing anything
The fourth choice:
- convince others that it is a problem, build a consensus and drive
action towards that effect. You keep telling me love it or leave it.
Maybe one day I'll leave it Stefano. I haven't given up yet. I just
have a lot of stuff to sort through before I can do it myself.
>
> is useless.
>
> Can Forrest be faster than it is today? sure. I think that with
> tweaking the sitemap and the component pools we can gain a lot of
> speed. Also I'm not sure how 'cache friendly' the Cocoon CLI is (that
> is another source of major speed gain).
That is my concern. Its not that usable in many cases at its current speed.
>
> Con Forrest be faster than Anakia? hardly. Anakia doesn't even parse
> the XML. It's a text generation system. It's designed for command
> line. It's designed for unstructured data. It's designed for small
> sites. It's designed with no idea of SoC.
Okay this is the practitioner versus the achedemic here. I don't care
about SoC if SoC means my docs come out in 10 minutes versus 1.
>
> In short, they are two different things that happen to have partial
> functionality overlap.
Exactly what practical thing does forrest do that Anakia doesn't other
than PDF generation?
>
> Andy, if you like Anakia more because it fits your needs, use that!
I usually do. I hope one day not to have to.
>
> And then complain to them about the fact that it doesn't this or that,
> even if it *doesn't* very quickly :-P
>
Sorry to burn your holy books... But I just want it to work fast enough
to use.
-Andy
Re: Including legacy html
Posted by Stefano Mazzocchi <st...@apache.org>.
Andrew C. Oliver wrote:
> So I'd say: to do as much as is necessary (and hopefully no more) to get
> the job done, in as much time as that takes provided thats
> reasonable. I do not believe Forrest meets this today.
I'd say that whoever feels that forrest is talking more time than it
needed it has two choices:
- get dirty with it and make it faster
- use something else
The third choice:
- complaining about it without doing anything
is useless.
Can Forrest be faster than it is today? sure. I think that with tweaking
the sitemap and the component pools we can gain a lot of speed. Also I'm
not sure how 'cache friendly' the Cocoon CLI is (that is another source
of major speed gain).
Con Forrest be faster than Anakia? hardly. Anakia doesn't even parse the
XML. It's a text generation system. It's designed for command line. It's
designed for unstructured data. It's designed for small sites. It's
designed with no idea of SoC.
In short, they are two different things that happen to have partial
functionality overlap.
Andy, if you like Anakia more because it fits your needs, use that!
And then complain to them about the fact that it doesn't this or that,
even if it *doesn't* very quickly :-P
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
Re: Including legacy html
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>
>uh huh. right. that's kinda what i figured. so never mind.
>
>
>
I didn't like it at first either Ken. But Nicola showed me the light and
now I'm free from
ever having to mess with such issues... I leave them all to him and just
whine when the
page looks ugly. Its worked for like a whole year now and I'm loving it!
And seriously conversion only hurt. Maintaining stuff in HTML tends to
hurt a lot. Its like the difference between having a oozing pulsating
ulcerated infected laceration on your side and cauterizing the wound
like Rambo. Sure the oozing pulsating ulcercerated infected laceration
hurts less at any given time, but over time it will spread and
eventaully kill you. Cauterizing the wound hurts way more all at once,
but less over a factor of time.
Therefore HTML is an oozing pulsating ulcerated infected laceration and
XML (and furthermore forrest) is the gasoline and torch to cure it. Its
pain, but its good pain! :-D
from:
http://www.geocities.com/TelevisionCity/Set/2366/idiotsguide/idiots5.html
"
Michael’s Tip for Cauterizing a Wound:
If you get shot behind enemy lines or left for dead by your team, you
can cauterize a gunshot wound by yourself. Simply separate several
bullet casings (2 are good 3 is better), and pour the gunpowder over the
wound, taking care to cover the wound thoroughly. Then ignite the powder
with a match or lighter. It’ll hurt like hell, but the wound should
close - if enough powder is used. Caution: Be careful not to use too
much powder or you could blow your arm or leg off!
"
-Non-Artistic Andy
Re: Including legacy html
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Nicola Ken Barozzi wrote:
>
> You ask to be able to make stuff pass through. Instead, we should say:
> what does that tag contain? What is the meaning it has?
>
> If something must be done to it or not is not the content editor to
> decide, but the styleshees, that can bypass or not.
>
> I know that it's difficult to accept, because content writers want to
> always tweak the style, but this is Evil (TM)
uh huh. right. that's kinda what i figured. so never mind.
Re: Including legacy html
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Rodent of Unusual Size wrote:
> "Andrew C. Oliver" wrote:
>
>>But then you're asking XML to take non-well formed stuff and put
>>it in, make the document non-compliant ill-formed HALF XML/HTML
>>(which will confuse the crap out of some browsers).
>
> you're definitely missing the point, andy. who said the output
> had to be html, or xml, or was to be read by a browser? it's none
> of the transformation engine's fscking business what the output
> format looks like; it's sole job is to take valid input and *create*
> the output according to its instructions -- however poorly-designed
> they may be. tools that try to be smarter than a competent user
> get up my nose, quite.
Almost right, but not quite. At Cocoon, and seemingly here at Forrest,
we bring forward the fact that content and presentation must be
separated, and that the engine should be able to adapt to *any* output
format it may want to.
So the tool *should* take valid input however poorly-designed they may
be. But we will define what valid input is, and do it thinking of this
separation.
So the question is wether this change would break this or not. Including
resulting content will possibly make presentation be used by content
authors (thing which broke and rammed semantical html in the first
place), and would make it impossible for the engine to cater for any
future format, because some content is available only in a defined format.
You ask to be able to make stuff pass through. Instead, we should say:
what does that tag contain? What is the meaning it has?
If something must be done to it or not is not the content editor to
decide, but the styleshees, that can bypass or not.
I know that it's difficult to accept, because content writers want to
always tweak the style, but this is Evil (TM), and the reason why I
disabled HTML mail in all my organization (they hate my even more
because of it :-> ).
>>Really Ken, in another year or two all that poor-formed HTML
>>(because well formed is XHTML which is XML) will make this
>>discussion the equivlent of discussing how to make sites render
>>nicely on 2400 bps modems.
>
> ha ha ha ha! (/me wipes eyes)
No need to laugh, if it all goes as it seems, we will have a Flash-only
web ;->
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Including legacy html
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
"Andrew C. Oliver" wrote:
>
> But then you're asking XML to take non-well formed stuff and put
> it in, make the document non-compliant ill-formed HALF XML/HTML
> (which will confuse the crap out of some browsers).
you're definitely missing the point, andy. who said the output
had to be html, or xml, or was to be read by a browser? it's none
of the transformation engine's fscking business what the output
format looks like; it's sole job is to take valid input and *create*
the output according to its instructions -- however poorly-designed
they may be. tools that try to be smarter than a competent user
get up my nose, quite.
> Really Ken, in another year or two all that poor-formed HTML
> (because well formed is XHTML which is XML) will make this
> discussion the equivlent of discussing how to make sites render
> nicely on 2400 bps modems.
ha ha ha ha! (/me wipes eyes)
Re: Including legacy html
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Rodent of Unusual Size wrote:
>"Andrew C. Oliver" wrote:
>
>
>>Ken, the biggest problem with including raw html is that its not "well
>>formed" which means its not valid XML. XML-foo doesn't like that.
>>
>>
>
>i think we're not communicating. stylesheet instructions are in xml.
>what they *act on* does not need to be, does it? i'm talking about
>an instruction 'include this external thing verbatim on the output
>side of the loop; don't try to do anything with it, it isn't for
>you. just include the frickin' thing right here in the output.'
>
>
But then you're asking XML to take non-well formed stuff and put it in,
make the document
non-compliant ill-formed HALF XML/HTML (which will confuse the crap out
of some browsers).
Really Ken, in another year or two all that poor-formed HTML (because
well formed is XHTML which
is XML) will make this discussion the equivlent of discussing how to
make sites render nicely on 2400 bps
modems. I think planning a little bit ahead is in order, and
furthermore, as a work around, just a link to such
a document can be included.
Furthermore, there are tools for converting HTML->XHTML. Nicola Ken
once suggested a few when I had
this argument (from the other side) with him (I used to author
everything in StarOffice and output to HTML).
Migrating can be done rather efficiently and even in a piecemail
fashion. I find once a project decides to do XML
the adoptation takes care of itself as the efficiency gains are
dramatic. (Not having to worry about presentation at all!)
>forrest can be as fast or as slow as it takes. is the primary goal
>do a little really fast, or do a lot in whatever time it takes?
>
>
Thats not particularly fair. For the purpose of generating HTML
documentation, forrest is unusually slow.
In Vegas, Stefano said this is because its using Cocoon and Cocoon is
still creating pools and all sorts of app server stuff that
won't be used.
Someone else stated that doing multiple passes exasserbated it (forgot who).
So I'd say: to do as much as is necessary (and hopefully no more) to get
the job done, in as much time as that takes provided thats
reasonable. I do not believe Forrest meets this today.
-Andy
Re: Including legacy html
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
"Andrew C. Oliver" wrote:
>
> Ken, the biggest problem with including raw html is that its not "well
> formed" which means its not valid XML. XML-foo doesn't like that.
i think we're not communicating. stylesheet instructions are in xml.
what they *act on* does not need to be, does it? i'm talking about
an instruction 'include this external thing verbatim on the output
side of the loop; don't try to do anything with it, it isn't for
you. just include the frickin' thing right here in the output.'
forrest can be as fast or as slow as it takes. is the primary goal
do a little really fast, or do a lot in whatever time it takes?
Re: Including legacy html
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Can I put in a word of caution? Forrest is already pretty slow... I'd
like to see some
thinking along the lines of "less passes" and perhaps a more pragmatic
approach to
those whom want extended flexibilty (perhaps by offering an "outside" of
forrest copy the thing or just
link it)..
Ken, the biggest problem with including raw html is that its not "well
formed" which means its not valid
XML. XML-foo doesn't like that. To be valid XML it has to be "well
formed" and for transformers and the
such, it must be. How can it be well formed? By being XHTML...
(basically "<p>bla" becomes "<p>bla</p>" and all
tags are closed, etc etc)...
Forrest needs to stay simple, and seek higher gradients of performance.
To be honest, I still don't like it as much as
anakia for doing what it does....because anakia is faster and takes less
memory! You can tout the wonderful technology
behind forrest all you want...but it still takes 10x longer to generate
a site so whoop-de-doo..
Its all about the speed and ease of use.
-Andy
Rodent of Unusual Size wrote:
>as far as that goes, is there any reason the dtd can't support an element
>that's meaningless except to the transformer, and executed non-recursively
>during transformation? something like:
>
><pre>
> <include-verbatim src="sample.raw"/>
></pre>
>
>i'm concerned about such things getting sucked in and then the result
>run through the sheet again; i'd rather see something like the above
>in a second pass.
>
>of course, i'm probably talking through my hat again.
>
>
>
Re: Including legacy html
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
as far as that goes, is there any reason the dtd can't support an element
that's meaningless except to the transformer, and executed non-recursively
during transformation? something like:
<pre>
<include-verbatim src="sample.raw"/>
</pre>
i'm concerned about such things getting sucked in and then the result
run through the sheet again; i'd rather see something like the above
in a second pass.
of course, i'm probably talking through my hat again.
Re: Including legacy html
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Rodent of Unusual Size wrote:
> "Peter B. West" wrote:
>
>>I doubt that I am the only one who will need to accommodate legacy html.
>
> it's not just 'legacy html' -- it's 'i need to include something that
> forrest didn't generate' and sometimes even 'i need to include a file
> with the same extension as one forrest knows how to make, but have mine
> included verbatim rather than forrest bitching because it can't find the
> source.' for example, pre-built pdf files that need to be included, but not
> built by forrest.
I see the need, and my proposal was in this direction.
Tha means that first thing Forrest should do is to see if the file is
there verbatim and use that, else see if it can generate it.
Current Forrest tried to do it, but it ends up in fu**ing up the links,
and this needs to be corrected. Not rocket science, but it needs to be done.
ATM, our discussion is not about including a single file verbatim, but
about whole directories. Cocoon makes the static site by crawling, and
sometimes this is not the best solution.
These problems affect only the crawler of the Cocoon CLI, and this means
IMHO that the problem is basically there. Try referencing the "static"
file from the webapp, and it will be served; try using the CLI, and it
won't. *This* is what should be fixed, we don't necessarily need new
semantics to define links to solve this problem.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Including legacy html
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
"Peter B. West" wrote:
>
> I doubt that I am the only one who will need to accommodate legacy html.
it's not just 'legacy html' -- it's 'i need to include something that
forrest didn't generate' and sometimes even 'i need to include a file
with the same extension as one forrest knows how to make, but have mine
included verbatim rather than forrest bitching because it can't find the
source.' for example, pre-built pdf files that need to be included, but not
built by forrest.
been there, done that, got irritated and discouraged..
Re: Including legacy html
Posted by Steven Noels <st...@outerthought.org>.
Peter B. West wrote:
> I doubt that I am the only one who will need to accommodate legacy html.
Sure.
> The attempts I have made include hacking the build.xml to copy html
> subdirs into the context directory, have failed. because the link
> resolution fails and I get an error page in place of the original.
>
> Is there some Q&D way to do this?
We're in the midst of a heated discussion to facilitate this, not only
on the generation/copying side, but also on the linking side of things.
If it's for intra-page stuff, I'm sure you know about <![CDATA[ ]]>
sections, which however are copied verbatim with the default text
entities escaped, and are there to include code examples.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: Including legacy html
Posted by "Peter B. West" <pb...@powerup.com.au>.
Jeff Turner wrote:
> On Sun, Dec 15, 2002 at 06:05:25PM +1000, Peter B. West wrote:
>
>>
>>I found real-content (deprecated) and added a copy of real-content-dir
>>with xdocs excluded to site-dir after the build
>
>
> Sorry, I forgot about that.. non-xdocs files in src/documentation/content
> are copied across by default:
>
> <!-- Copy all non-xdocs content -->
> <target name="copy-content" if="real-content.present">
> <copy toDir="${project.ctxt-dir}/content" filtering="false"
> overwrite="true" failonerror="false">
> <fileset dir="${project.real-content-dir}">
> <exclude name="xdocs/**"/>
> </fileset>
> </copy>
> </target>
Jeff,
They are copied across, but AFAICT, the links still fail. However,
copying them again after the build establishes the correct links,
overwriting the generated cocoon error messages.
Peter
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
Re: Including legacy html
Posted by Jeff Turner <je...@apache.org>.
On Sun, Dec 15, 2002 at 06:05:25PM +1000, Peter B. West wrote:
> Jeff Turner wrote:
> >On Sun, Dec 15, 2002 at 03:38:51PM +1000, Peter B. West wrote:
> >
> >>Forrest-devs,
> >>
> >>Is it possible to include legacy html in a forrest-generated site?
> >
> >
> >Apparently, adding xlink:role="dynamic" to the link will stop the crawler
> >from breaking on the link. Then the file(s) could be copied over by an
> >Ant task.
>
> Jeff,
>
> I found real-content (deprecated) and added a copy of real-content-dir
> with xdocs excluded to site-dir after the build
Sorry, I forgot about that.. non-xdocs files in src/documentation/content
are copied across by default:
<!-- Copy all non-xdocs content -->
<target name="copy-content" if="real-content.present">
<copy toDir="${project.ctxt-dir}/content" filtering="false"
overwrite="true" failonerror="false">
<fileset dir="${project.real-content-dir}">
<exclude name="xdocs/**"/>
</fileset>
</copy>
</target>
--Jeff
PS: As for the name 'real-content': for some reason, the directory
'src/documentation' was assigned the variable name
${project.content-dir}. Which is very silly because right underneath,
is a content/ directory. When I found I needed to address that too..
name clash, hence ${project.real-content-dir}.
Re: Including legacy html
Posted by "Peter B. West" <pb...@powerup.com.au>.
Steven Noels wrote:
> Peter B. West wrote:
>
>> P.S. have you found a bearded SGML guru.
>
>
> We don't have limits on the amount of gurus. You should stop shaving
> however: http://homepage.powerup.com.au/~pbwest/pbw01.jpg ;)
>
> </Steven>
Steven,
That's only one of the things that rules me out.
Peter
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
Re: Including legacy html
Posted by Steven Noels <st...@outerthought.org>.
Peter B. West wrote:
> P.S. have you found a bearded SGML guru.
We don't have limits on the amount of gurus. You should stop shaving
however: http://homepage.powerup.com.au/~pbwest/pbw01.jpg ;)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: Including legacy html
Posted by "Peter B. West" <pb...@powerup.com.au>.
Jeff Turner wrote:
> On Sun, Dec 15, 2002 at 03:38:51PM +1000, Peter B. West wrote:
>
>>Forrest-devs,
>>
>>Is it possible to include legacy html in a forrest-generated site?
>
>
> Apparently, adding xlink:role="dynamic" to the link will stop the crawler
> from breaking on the link. Then the file(s) could be copied over by an
> Ant task.
Jeff,
I found real-content (deprecated) and added a copy of real-content-dir
with xdocs excluded to site-dir after the build (and complaints about
the broken links.) That will do for now, but it would be nice to get
something formalised.
Peter
P.S. have you found a bearded SGML guru.
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
Re: Including legacy html
Posted by Jeff Turner <je...@apache.org>.
On Sun, Dec 15, 2002 at 03:38:51PM +1000, Peter B. West wrote:
> Forrest-devs,
>
> Is it possible to include legacy html in a forrest-generated site?
Not currently. There is a patch which supports this via a file: scheme,
eg <link href="file:generated-code.html"> would link to that static file
in src/documentation/content. The patch was -1'ed and we're still
arguing about it. If you really need it, run 'cvs update -r
with_file_scheme' in xml-forrest/
> I cannot see a way, so I would appreaciate some advice. My particular
> requirement is to be able to include XE/e/macs htmlized code, or
> fragments thereof, in generated code. The ideal would be to be able to
> insert chunks directly in the generated pages, but I realise that this
> is probably asking too much.
I'm sure it could be done, but not AFAIK with off-the-shelf code.
> As a fall-back, the ability to correctly refer to complete html pages
> in, say <jump/> elements would suffice. I am thinking of having such
> pages, or subtrees of pages, in the resources directory under
> src/documentation.
>
> I doubt that I am the only one who will need to accommodate legacy html.
_Plenty_ of people want to link to all sorts of static docs.. HTML, PDFs,
zips, etc. It's the biggest problem in Forrest today.
> The attempts I have made include hacking the build.xml to copy html
> subdirs into the context directory, have failed. because the link
> resolution fails and I get an error page in place of the original.
>
> Is there some Q&D way to do this?
Apparently, adding xlink:role="dynamic" to the link will stop the crawler
from breaking on the link. Then the file(s) could be copied over by an
Ant task.
--Jeff
> Peter
> --
> Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
> "Lord, to whom shall we go?"
>