forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Todo list in generated Forrest docs
Date Tue, 22 Oct 2002 17:40:59 GMT

Jeff Turner wrote:
> On Tue, Oct 22, 2002 at 05:25:23PM +0200, Nicola Ken Barozzi wrote:
> ...
>>>Which files?  I am always happy to oblige when it comes to rants. :)
>>the xdocs one; hey, _you_ wrote that subtle rant! :-P
>>Let's just have to set one "documentation" dir that contains in the
>>same dir structure all files.
>>Just remove the content/xdocs part and the resources/images part and
>>put them in the documentation dir... if it works, that is, you'll need
>>to check ;-)
> I have a FIFO rant buffer. 


> Was I having a whinge about having to type
> 'src/documentation/content/xdocs'?  If so, that is now kinda fixed.

It's still in the docs, though :-D hahaha

> There is an example in your-project.html of how to use a short Maven-like
> /xdocs, /xdocs/images structure.  Remapping happens in

Yes, exactly that.
We could as well get rid of it entirely and go with a single dir structure.

This is not only a rant from you, but an important conceptual notion:
we are using URIs to define the content, while URIs must only 
represent... concepts (sort of).

Hence the CAP discussion & friends.
I joked about your rant thing, but in fact it's important.

We should not only enable /images, but **.
For now extensions will suffice for the contenttype, later we'll see to 
get more into CAPs.

>>>- Long term: use Christian Haul's new chaining input module.
>>Where is it? Has anyone seen it? ;-)
> Remember those two pages of '' commit logs you scrolled
> through a few days ago? :)

These days are a roller coaster, since the reorg in place and the 
creation of the incubator and the book and Centipede and the Messe at 
Duesseldorf and the mailserver at work that they are making me get it to 
work and I'm just married (funnily it's the easiest part), etc... ;-)

> Actually, I'm not certain what Chris committed fully meets our needs.  If
> it turns out not to, I'd rather get the old @skin@ system working again
> for 0.2, rather than wait for Cocoon.  The two systems are functionally
> identical, though input modules are conceptually nicer.  We'll see..

Take a look and report here, we'll see if it can eventually be fixed 
sonn, or even if it works OOTB!

>>>- Fix bug
>>>- Repackage Forrestbot (currently requires manual hacking)
>>Could you please elaborate more on this?
> See email entitled "Where goes Forrestbot?".  Currently the forrestbot
> isn't packaged in an end-user friendly fashion.

Ah, ok, the bot. +1

>>I really like the sbat distro.
> Good-o.  Marc was right about the shell scripts.. it's nice being able to
> type 'forrest seed webapp' in an empty directory, and bang, there's a
> template site waiting to be edited.

Yes, that's awesome!

>>>- Anything else necessary for a 0.2 release.
>>Ha, +1 for making Jeff do a lot of work ;-P
>>>- Write Maven plugin against 0.2
>>Put this just after the skin bug, IMO it's more important than the 
> Aw.. repackaging is fun.. guess you're right though.
> Add to todo list: incorporate ideas filched from Robert's LSB.


>>>(IOW: let's not cause a flamewar by proposing that as a replacement for
>>>the current Anakia-driven site ;)  At least, not yet.)
>>If you really feel you want to become our hero, then just take the 
>>smallest web server you can find, make Environment classes for it for 
>>Cocoon, put it in the Forrest distro, and make a forrest view target.
> Kinda.. ?
> Briefly:
> - We need on-the-fly XML to HTML conversion
> - Cocoon is way too 'heavy' to run from the command-line. Can never
>   compete with DVSL, Anakia etc.

And even if it does, webapps are still faster to work with, no need to 
launch a script.
Cocoon is fast enough for me now for what it has to do, but for everyday 
editing you are just plain right about the webapp.

I thought initially that it was a nice possibility, but really haden't 
realized how it was pivotal.

> One solution: turf out the CLI interface and use Cocoon as a webapp.

Errr, yes, that's what I said...

> 'forrest view' launches an internal webserver.  What you were thinking?


I was already talking about implementation details.

Basically, what has to be done is:

  0.5) grab a lightweight webserver
  1) create all the o.a.c.environment.* abstraction classes needed
     to run Cocoon in the webserver
  2) create a entry point
     (like Cocoonservlet and Main)

  3) tadaaaaaa!

>>Oh, and on top of that add to the sitemap the SourceWriting stuff so
>>that from each page we can edit it in place.
> Certainly we need to get rid of the 'cp src/documentation/*
> build/tmp/context/' step.  Input modules remove the main technical
> obstacle to being able to edit src/documentation/.../index.xml and
> immediately see the change in a webapp.


But having the possibility of clicking a button on the page to see the 
source, edit it, -save- and see the result right away would be heaven...

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message