Adam R. B. Jack wrote:
That's site.xml

So can I create a template site.xml, or do I need something dynamic? Sorry, looking for a big assist. :-)

Ok, then I'll have to run the baby ;-)


I've been busy in these weeks so I followed the mails briefly; what should I do to run it and where should I look into to see what to change?

Is there a nicer way?

In which sense 'nicer'?

I guess, more "traditional gump-like". Ought site be the log directory, ought I create content/xdocs in some other place. I guess trying to be more like traditional gump.

Just do the easiest thing for now, it's not important (and I never liked where Gump put things, but again I never changed it as it's... again not important).


Can you please explain better the usecase? I reckon that a single Gump
run will have a single skin to be used in the site generation.

I was thinking that we'd ship a Jakarta-Gump skin & resources, like the one the Jakarta-Gump site uses, but then a site might wish to override it's logo, it's skin, etc. I am setting up Gumps internally @ work, and much as I give Jakarta Gump credit I'd like to brand our results as Sybase (to make my target audience more accepting).

Ok, I guess my brain is frying after working too much, now I get it.


So, let's say that Gump is like forrest. As Forrest can be run on a Project docs, Gump can be run on a workspace definition.
Let's now expand Gump so that it can run on a workspace project: in your case you would create a sybase-gump project:


 sybase-gump/
    forrest.properties
    status.xml
    workspace.xml (not the usual module.xml)
    src/
      documentation/
        skinconf.xml
        resources/
          images/
            group-logo.png
            project-logo.png
        content/
           xdocs

We would run then Gump on this workspace, and it would use this project to create the default work dirs, the default result dirs, and use the Forrest site, by adding the generated docs in a special src/d11n/content/xdocs/gump dir, or have gump first copy the site to a temp dir and add the generated docs there.

In this way we finally are able to decouple the jakarta-gump project from the installed instances.

3 - wait till we enable the "class" attribute in all elements and make
    a special Gump skin that enhances that Forrest one
    - drawbacks: non standard skins, cannot use readymade ones

I have *no clue* on forrest internals, so I am in no real position to judge if this is good/bad or ugly. That said, if I could easily add 'class=ERROR' or something to a <TR or <TD or whatever, wouldn't existing skins/stylesheets just ignore it? Could I not somehow cascade a small stylesheet for this feature on top of existing ones? [Forgive me if I am confusing old CSS stuff w/ forrest stuff & talking junk... :-)]

If Forrest had a defineable user-stylesheet, yes. Currently it does not, but it seems that it's the easiest and best thing to do.
I'll see what I can do tomorrow morning.


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



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to