james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Brewin" <sbre...@synsys.com>
Subject RE: site process
Date Thu, 16 Dec 2004 16:56:19 GMT
Serge Knystautas wrote:
> Steve Brewin wrote:
> > We seem to have at least four distinct issues here...
> >
> > 1) The document source format which is difficult to develop
> and maintain
> > without a WSIWYG editor that natively supports the chosen format.
> >
> > 2) The task(s) used to transform each document from source format to
> > presentation format.
> >
> > 3) The organisation of the content.
> >
> > 4) The build tool used to drive the task(s) in (2).
> I can't even stick to my words yesterday that I wouldn't
> mention Confluence.
> So what about using Confluence for content creation and
> maintenance?  We
> can either setup templates to output this as xdoc or use an ant task
> that uses XML-RPC to grab the latest content from confluence
> and updates
> what's in SVN.  Here's something Codehaus uses for something similar
> http://despots.codehaus.org/Confluenza.
> Ok, sorry I'm wrambling, but I just what to drastically cut
> the number
> of steps and required expertise to update our website.  Right now we:
> 1. checkout james
> 2. edit the xdoc
> 3. run ant task to transform
> 4. review HTML and return to step 2 as necessary
> 5. commit xdoc and html
> 6. ssh in and update the html
> I would want to remove the effort between steps 2 and 4 and also
> automate steps 1 through 6 as much as possible.  I see confluence as
> able to achieve that, but really that's all I want.

What you are describing here is a document publishing system, and yes, it
would be cool to be able compose, submit, review and apply changes in a
secure version controlled environment.

Reading the Forrest documentation, <<IF>> it is stable enough, we could use
Forrest's web. app. to submit and review pages. Once we are happy with them,
we could then invoke forrestbot or Ant from the same web. app. to add them
to SVN and deploy them to the live server.

This doesn't tackle composition. I would prefer to be able to point the web.
app. at a URL pointing to source format documents and treat their
composition as a separate problem. The pages could be generated using
Confluence, via access restricted pages on our current Wiki, with
OpenOffice, or as Noel has just pointed out, using plain old emacs.

-- Steve

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message