forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [PATCH] customizable skins, greater configurability, image di r fixes, miscellanea
Date Fri, 13 Sep 2002 14:54:34 GMT

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 <xmlproperty> 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:
> 
> <target name="webapp" description="Build the website webapp">
>   <ant antfile="${forrest.home}/forrest.build.xml" target="webapp"/>
> </target>
> 
> 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 <exec> 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)
---------------------------------------------------------------------


Mime
View raw message