Return-Path: Delivered-To: apmail-xml-forrest-dev-archive@xml.apache.org Received: (qmail 70683 invoked by uid 500); 22 Oct 2002 17:42:17 -0000 Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: forrest-dev@xml.apache.org Delivered-To: mailing list forrest-dev@xml.apache.org Received: (qmail 70639 invoked from network); 22 Oct 2002 17:42:11 -0000 Received: from mail-6.tiscali.it (HELO mail.tiscali.it) (195.130.225.152) by daedalus.apache.org with SMTP; 22 Oct 2002 17:42:11 -0000 Received: from apache.org (62.10.44.25) by mail.tiscali.it (6.5.026) id 3DAE56AB002FFAB1 for forrest-dev@xml.apache.org; Tue, 22 Oct 2002 19:42:10 +0200 Message-ID: <3DB58DAB.6070106@apache.org> Date: Tue, 22 Oct 2002 19:40:59 +0200 From: Nicola Ken Barozzi Reply-To: nicolaken@apache.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: forrest-dev@xml.apache.org Subject: Re: Todo list in generated Forrest docs References: <20021022122647.GA5545@expresso.localdomain> <3DB54455.3040501@outerthought.org> <20021022130325.GB5545@expresso.localdomain> <3DB5587B.90602@apache.org> <20021022150758.GC4613@expresso.localdomain> <3DB56DE3.5010809@apache.org> <20021022170522.GC5545@expresso.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Status: O X-Status: X-Keywords: 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. ROTFL :-D > 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 forrest.properties 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 'haul@apache.org' 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! >>>>Plans? >>> >>> >>>Personally: >>> >>>- Fix forrest.skin 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 >>repackaging. > > Aw.. repackaging is fun.. guess you're right though. > > Add to todo list: incorporate ideas filched from Robert's LSB. -add- >>>(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? Yup! 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 EmbeddedServer.java 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. Yes. 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 nicolaken@apache.org - verba volant, scripta manent - (discussions get forgotten, just code remains) ---------------------------------------------------------------------