Forum OpenACS Development: Has anyone improved the Static Pages package?

Since it sounds like "DaveB" (Dave Bauer?) is partly done with porting the Static Packages package, I figure he and other folks here might have some ideas on its shortcomings and how to fix them. So, I'd like to draw all your attention to the thread I just started over on web/db: 'Has anyone improved ACS Static Pages package?'.
Such threads really belong over here if you're interested in running the Tcl version, because no one over there will be working on it ...

Since the content repository has been enhanced to allow storage in the filesystem rather than in the database (as an option), we've been planning to extend this slightly further so the static pages package can use the CR to do its mapping rather than its own table structure.

Since the CR knows about a variety of file formats extending static pages to reflect that shouldn't be all that difficult.  We don't have filters at the moment to rip content out of PDF files for sitewide searching (do we?  I don't think so.  I wish we did) but commenting on them should fall out of this scheme at no cost.

Site wide searching and the kind of knowledge-management categorizations that folks have talked about in other threads would also fall out of this scheme "for free".

As far as deleting comments on static pages that are deleted, the only
place such comments appear is in association with the page.  So once the page is gone there's no place to put the comments and of course the reader of the comments wouldn't be able to read the document being
commented on.

So I can see why it was implemented that way.

But with the CR approach we could do it differently easily enough, probably as an option, if there were strong feelings that it's useful.
Keep the CR object around in a deleted state and give some UI hook for
admins, at least, to get to general comments made on deleted pages.

Something like that.

On the deleting comments thing, I feel strongly that simply re-scanning the file-system for static pages should never delete content. Imagine this scenario:

I re-organize my whole web site. Perhaps I'm even thorough enough to set up some sort of auto-magic redirection from the old locations to the new ones - perhaps not. Either way, I go and tell Static Pages to re-scan my file-system and learn about all the new locations. But, oops, there go all my page comments, out the window! Do I have a current backup handy?

Instead, when a file "disappears" from the file-system, Static Pages should simply stamp its record of the file as "broken as of DATE". That way, the system admin can come back later and either point the comments to a new instantiation of the page, perhaps archive the comments elsewhere, or choose to junk all the comments. But user-contributed content should never just be transparently disposed of without human intervention.

Collapse
Posted by Don Baccus on
Oh, I see what you're getting at, this makes sense, yes.  A file might
be randomly deleted for all sorts of reasons and zapping all the db content pointing to it in that case would be very annoying.

Especially if we set things up so you can have the static page package
scan your site for you automatically at intervals so you don't have to
remember to do this manually when you add pages (for all I know the aD
static page package already does this).