forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Portier" <...@outerthought.org>
Subject RE: libre status (was RE: XHTML2 I have read it and I like it... GO READ IT!)
Date Mon, 12 Aug 2002 18:14:29 GMT
> > Taking it really off topic: (but realted)
> > What I'ld like to see (out of my league and time-schedule :-(,
> so here is an
> > itch I don't think I can scratch myself) is some doc that describes the
> > "resources" (other then the sitemap: human readable please)
> > It should be the base for thinking (and discusussing) about
> more of what we
> > want to slide into TheContract we offer.
> > (metrics, junit, jdepends, syntaxhighlights, kinds of navigations, the
> > tabs???, ...)
> >
> > It could be a basis for deviding work as well...
> >
> > If we're doing this meta-web thing (forrest) the full cocoon
> way, carefull
> > thought about the URI space we manage should be our prime concern?
>
> Yes, this is the question I wanna ask you all...
>
> Currently, we have our sources in src/documentation.
> Then we copy them to a place where they are built.
> As already said, other tool place their docs somewhere too, in the right
> format, and Forrest should be able to pick them up.
>

to help thinking: such other tools could be the cents now in centipede:
jdepend, junit test results, a locally ran kind of gump, the syntax
highlighter, the umljavadoclet, ...  stuff that can't be ran in a generator
(let allone that you wouldn't want to do it)


there is a number of roles in the play
1. us forresters: we can fix all dirs and sitemap, decide which content
portions are required/optional...
   I'ld like to see us do this in terms of xlayout references in stead of
fixed dirs, that would allow other ant tasks to fit in more nicely.
Drawback is that sitemap will not pick up the xlayout stuff (same problem
with the @skin@ maybe an xslt producing the sitemap is an option? )

2. project builders: actually my feeling is they should just do that: write
up all inside the ./src and nothing more

3. site publisher: the one that decides which portions of content should be
created and published, how they hook up into a navigation --> this means
editing book.xml's (or less libre configs in future) as well as editing
build.xml (??? doesn't sound right, should be more properties.xml work if
you ask me)

4. another site publisher (same cvs co published to different sites, other
skins, same relative URI spaces though): editing/overriding similar
properties in some sort of bot conf


> The problem is: where?
I would go for defined xlayout names that people can change to their need by
editing layout.xml
 and make sure we have some mechanism for generating a sitemap that knows
about these 'changes/customizations'


As I mentioned to Nicola in private earlier I believe that this layout.xml
could help around in the bot as well.
Point is that if we'll going to gump-like build more stuff in one sweap
(forrest at the end of a list of cents that have generated their stuff) we
need to have a build-file flavor that allows to actually make the produced
targets available

Point is build files only make their target-names public, meaning you can
call them, and they produce whatever target you ask them (and you chain up
dependencies) but you can't get TO the target (the side effect is there, the
return type is void if you like.  Build files make something, they don't
'return' something.  While this is great hiding of the implementation it
makes it very hard for various more indpendent processes (cents) to actually
find and use what the other one just build.


> Which URIs are used?
I would let this lead the discussion. rest should follow...
maybe we can list what we have/want and drop in suggested URI-names?

list of haves is:
- dtdx
- xdocs
- faq
- status page (todo)
- changes


up to the wants?
- syntax highlight source code
- maillist archive
- javadoc with uml via xdoc
- books of assembled file snips
- ...


I know Steven started off an ambitious idea on having content aware
pipelines on cocoon-dev, which will surely produce some usefull stuf, but
that doesn't mean we should be (in the mean time) throwing all types of
files just in a big heap and then just see what happens, right?

To organize this out, we have plenty of flexibility in 3 places:
1. defining the url to get it (*.dtdx.html is a good example, the faq could
use the same no?)
2. the navigation (book.xml and overly promised successor)
3. organize/decide where to store it on disk
there is mappings available between them, so we get the nice SoC everyone
likes?

(the content-aware pipelines would make the choice of DTD for a document a
4th flexibility parameter)

(come to think of it, this sounds as enough flexibility so we pretty much
should be able to start off without user definable xlayout dirs if you ask
me, it's just that they are in cvs and more thight to the project using
centipede then to using forrest, meaning people will consider changing it
based on centiped use, and drwan back by forrest possibly not letting them?)

Nicola, I guess centipede would suggest its users to change their layout.xml
at will, right?




> How do we link (also with libre...)
> :-?
Should follow from the full request namespace.

The top down linking with book or libre should be fairly ok I guess, the
cross refs between te docs are the ones that come under the realm of actual
editors... and that's a bit more nasty... starting to think about something
like layout.xml again, and references that can be looked up there?


-marc=
PS: Have been looking at how some of my messages end up on the list...
    As a big sorry for all the typos in past and future mails, I should let
you know I have a great mentor in this:
http://www.brainyquote.com/quotes/quotes/a/q138608.html and
http://home.freeuk.com/elloughton13/aamilne.htm for more



Mime
View raw message