Ian Bicking (ianb@...) wrote:
> > We needed a system that would take content from an internal web
> > server and, through a workflow process, let management types
> > "approve" versions of documents for publication. Approved documents
> > are versioned, metadata regarding the transaction is archived, and
> > then they get pushed out to our external web server. This way, the
> > external box contains an image of the web tree containing only
> > documents that have been authorized for publication.
>
> So you're publishing statically, generated from Webware? How do you
> handle linking as the document moves locations?
Well, Webware doesn't "generate" any content, really. Like I mentioned
in my reply to Van, we have a 2 server setup at the lab. One box is
inside the firewall and used as the staging server, and the other is in
the DMZ and is the production box.
Webware just provides an interface for management/legal types to go
through the workflow process. When they mark a web page or pdf or
whatever that's on the staging server as "approved", that document is
versioned and then is marked by the backend as being "approved" for
publication. Then periodically, approved documents that aren't yet on
the production box (or documents that have changed) are pushed out to
the production box.
Webware doesn't actually create any pages, via automatic templating or
anything. Our web developers specifically didn't want a system like that
because they wanted to use the tools they've always used (Dreamweaver or
Frontpage or whatever) instead of using some web interface to edit pages
and link resources together, a la Zope.
But none of that really answers your question. :) Basically, to preserve
links when we copy from one box to another, we saw 2 options:
The first option is to configure DNS so that the name 'www' points to
the staging server when you're inside the firewall, and points to the
external server when you're outside. Then you can use absolute links to
your heart's content. :) The problem with the second approach is that if
a developer wants to browse the external website and is inside the
firewall, he's out of luck.
The second is to just tell the developers to use relative links. And if
they *have* to use an absolute link for some reason, we've set up an
apache variable that they can include that will give them the name of
the host they're running on. The tools our developers use seem to do
relative linking by default, so it really hasn't benn too much of a
bother to them.
We were thinking about adding code that would do search-and-replace on
html files, swapping in the name for the external box whenever we saw
the name of the staging server...but since the nobody complains about
the relative linking policy, I never implemented it. :)
> I'd be quite interested in the code you use with CVS. Or
> Subversion... I'm really interested in it, but haven't had a chance
> to really work through it. But CVS is more Here And Now.
The CVS code is ugly and not very interesting. :) It basically runs
'cvs' and parses the output. It would be *so* much nicer if there was an
actual libCVS, but the only similar thing I could find was an incomplete
Perl module. I was debating writing a Python pserver client, but then I
decided to check out Subversion.
Surprisingly, Subversion is quite stable from the testing I've done. And
really well documented, to boot. There's an actual C API, which is
great. There's a Python API (done via SWIG), but I believe that it's
incomplete. Subversion also has a WebDAV interface, which is pretty
nifty. But one of the most interesting features of Subversion is that
file can have metadata (properties) attached to them, and they are
versioned as well. The metadata can be textual or binary.
Now *that* feature could be exploited to allow users to add arbitrary
notes and properties to files that are approved for publication, and
those attributes can be versioned automatically by Subversion. Right
now, I'm tracking metadata in a relational database, but the consequence
of that is that there's no real coupling between a row in the database
and the file in CVS, except for the filename and the date the file was
checked in. Subversion will go a long way towards ameliorating the
situation. Finally I'll be able to provide a web interface for rolling
back document revisions, etc.
A Python pserver client would be a nifty little project, though. :)
> > There is authentication and a permissions editing interface, but
> > it's pretty specialized for my application and I doubt that it could
> > be seperated out in any meaningful way for use in a CMSKit. We use
> > external tools for user/group management.
>
> [...] Actual permission management would require something
> domain-specific (to match your underlying model), but the simple "can
> user X do action Y to resource Z" interface should be possible to
> abstract.
The permissions model we're using is basically a simple table that has a
username/groupname, a path, and a number representing a permissions
"level". The row represents what level of permissions a user/group has
for a certain filesystem path (we use the filesystem path because that's
what users operate on in our app, though it could just as easily be a
URI). That 'level' corresponds to a row in a permissions matrix that
tells what actions are permitted and which ones aren't.
We've hardcoded the permissions matrix since the possible actions a user
can do are very well-defined in our app. But abstracting it out wouldn't
be hard to do.
In any case, when work on a PermissionsKit or whatever starts, I'd be
happy to contribute.
Cheers!
Deepak
--
Deepak Giridharagopal
The University of Texas at Austin, Applied Research Laboratories
Check out Ganymede, a GPL'ed metadirectory for UNIX:
http://www.arlut.utexas.edu/gash2
|