Return-Path: Delivered-To: apmail-xml-forrest-dev-archive@xml.apache.org Received: (qmail 2529 invoked by uid 500); 13 Sep 2002 14:55:52 -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 2454 invoked from network); 13 Sep 2002 14:55:50 -0000 Received: from unknown (HELO aisa?2nd.aisa) (194.184.10.202) by daedalus.apache.org with SMTP; 13 Sep 2002 14:55:50 -0000 Received: from apache.org ([192.4.0.103]) by aisa_2nd.aisa (Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) with SMTP id C1256C33.0053BC0B; Fri, 13 Sep 2002 17:14:36 +0200 Message-ID: <3D81FC2A.80300@apache.org> Date: Fri, 13 Sep 2002 16:54:34 +0200 From: Nicola Ken Barozzi Reply-To: nicolaken@apache.org Organization: Apache Software Foundation 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: [PATCH] customizable skins, greater configurability, image di r fixes, miscellanea References: <20020913112003.GD2419@expresso.localdomain> <3D81D7FD.40801@apache.org> <20020913143718.GG2419@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 Fri, Sep 13, 2002 at 02:20:13PM +0200, Nicola Ken Barozzi wrote: > >>Jeff Turner wrote: >> >>>On Fri, Sep 13, 2002 at 01:35:36PM +0400, Piroumian Konstantin wrote: >>> >>> >>>>>From: Jeff Turner [mailto:jefft@apache.org] >>>> >>>... >>> >>> >>>>>These changes were made while producing the site at >>>>>http://aft.sourceforge.net/ >>>> >>>>Seems that Forrest's skin is the favourite one. We already have at least 3 >>>>sites with the same skin. >>> >>>I like the Krysalis one (avalon-site) though. I think this patch would >>>allow the krysalis skin mods to be rolled back into avalon-site. >> >>Cool :-) >>Well, we have changed the skin at Avalon, as you can see >>http://jakarta.apache.org/avalon/ , and I've done some minor >>enhancements for the text of the krysalis one. > > > Hey yes, I'm also an Avalon committer.. ;) It was for the others, stupid fellow ;-) > So if I want to fix up the avalon-site skin so Avalon can use it, which > would be the one to use? > > jeff@expresso:~/apache/jakarta/jakarta-avalon/src/documentation/skins$ ls > alt-avalon-site avalon-site avalon-tigris basic CVS krysalis-site avalon-tigris >>Many people have asked me to decouple the skin repository from Forrest >>itself, do you have any ideas on how this can be done well? > > Sounds odd.. what use is a skin on it's own? Perhaps the style.tigris.org > people have something going. It's because some want to keep their skin in their repository, but still have projects be able to reference and use it. Basically Avalon could keep his skin and other projects could use it too... >>>>>The patch does the following: >>>>> >>>>>- Allows users to have a custom sitemap, overriding the >>>>>forrest-provided one. Default location is >>>>>src/documentation/sitemap.xmap, though it is configurable. >>>> >>>>Why not the src/resources/conf? >>> >>>That's where it lives in Forrest's CVS module, where it is indeed a >>>"resource". But inside a live Forrest-using project, it's not a static >>>"resource", but the active controller. It specifies how resources >>>(images, xdocs) are mapped to URIs, so it's not a resource itself. Thus I >>>followed the Cocoon example of putting it at >>>src/documentation/sitemap.xmap. It's configurable of course. >> >>I have been thinking about the dir layout we ask our users to have... >>Since we have decided that we put all in the same dir, with the >>possibility of having also them in indipendent dirs, what about this >>default layout: >> >> */documentation/fdocs (forrest docs) > > > ie, xdocs live here? yes >> */documentation/fdocs/images > > > .. and images linked to from ../*.xml live here? yes > If so, big +1. I'm greatly in favour of anything that allows simpler doc > layouts for simpler projects. > > >>>Putting them in lib/ might interfere with other jars there, and might >>>cause unforseen interactions with either Cocoon or the user's app. >>>lib/optional and lib/endorsed are Centipede specific. How about lib/doc/? >>>Hmm.. if your project doesn't have a lib/ directory anyway, it would look >>>a bit silly. The intention with src/documentation/lib is that all doc >>>stuff (xdocs, stylesheets, images, jars) are in one directory. >> >>We should decouple the doc dir from the doc-generation enhancements dir. >> >>What about >> >> */documentation/fdocs (forrest docs) >> */documentation/fdocs/images >> ... >> */documentation/resources/images >> ... >> */ext/sitemap.xmap >> */ext/lib/ >> ... >> >>? >> >>In this way it can be easier to decuple the exts later on and make a >>specific forrst enhancement plugin. (mayby plugin instead of ext?) > > forrest enhancement plugin.. hmm, like, a "user feedback" plugin, or a > wiki plugin, or a CMS plugin.. is that what you mean? Sounds cool. Yes, it would need to be synched with the Cocoon block stuff though later on. > ... > >>>Yes it would be nice. However the 'processor' is the task, >>>and unfortunately it provides no way for accessing the n'th link. >> >>We can get round this quite easily with two ways: >> 1) I patched the xmlproperty task (@see Ant Bugzilla) to make multiple >>entries result in a comma-separated list on which the for-each task can >>iterate > > > Wohoo:) > > >> 2) We update to the latest Ant embed proposal and use JXPath >> http://www.krysalis.org/cgi-bin/krywiki.pl?AntJXPath > > > Even better. > > Would be nice if we could keep Ant 1.5 compat though. Technically it's still Ant1.5 since you don't change the jar, just add a sax2.jar in ant.home/lib... > Let's say a typical > Forrest-using project invokes Forrest with: > > > > > > Seems a bit much for a doc system to force a version of Ant on users. > > But then maybe Marc is right and users will all use a 'forrest' script > instead. And we can always Forrest. I have made a "callcent" script in centipede now. Basically you just install Centipede, and then you can execute any cent-plugin with callcent plugin.cent so it would be callcent forrsest.cent Why? Because we can finally make tools that can run indipendently or as cents, and not require to repeat all the common stuff in each of them. What do you think? -- Nicola Ken Barozzi nicolaken@apache.org - verba volant, scripta manent - (discussions get forgotten, just code remains) ---------------------------------------------------------------------