Jørn Wildt

I am now beginning to look at untrusted submissions for Pagesetter and could use some inputs for a spin-off idea from that ...

One thing is to allow untrusted authors to submit new items - I believe I have enough ideas to solve that problem. Another problem is how to handle later corrections to the submitted publication.

In a news handling setup there's no need for later corrections. The author submits the article, the publisher approves it, and that's it. Soon after it is too old and no one's going to change it.

In an online list of static publications there's seldom no need for untrusted corrections. In a recipe system there's no need to change the recipe, and if there is then the publisher can fix whatever errors found in the recipe - it is so seldom done, that the burden should be small enough to let the publisher administer.

But for an online list of more dynamic publications you want your community to keep updating the list. Take for instance Lexebus' list of all PostNuke modules (see http://www.lexebus.dk/index.php?module=pagesetter&tid=3) - here he wants to depend on the community for updates, since keeping track of everything is impossible for a single person.

One way to handle this problem is to let untrusted users edit existing pages - much like a Wiki I think. But how do one implement such a thing? Here I would like some input from those of you that have expirence with this kind of applications.

Should updates be submitted in a separate table? In this way you have the original version online and the new data in a separate database table. Approval of the update means moving data from one table to another. Personally I do not like this idea, it smells somehow (cannot pin-point why) and seems clumsy.

I think a Wiki approach would be better with a complete revision log - that's also what a commercial system offer, and it is something other users have requested. But how should that sort of thing be implemented?

1) All revisions could be stored in the same database relation as the "live" revision. All displaying of a publication would then restrict the view to the version marked as "current" (not the latest - you might want to mark a previous version as current). So extra logic is need to filter out the current version from the other ones.

2) Old versions are stored "off-line" in another database table. In this way all the existing Pagesetter logic works as it has always done. But new additions/updates are inserted in a separate database table. Marking something as "current" means copying it into the normal database.

So - can anyone with some database expirence please help me with the decision - all revision in *one* table, or "off-line" revisions in a separate table?

[Edited on 8/3/2004 by J?rn]

Thank you for mentioning the LEXeBus project, and thank you for taking this matter so serious.

I see two different approaches here.

1. To change the doument/publication
2. To add changes for the document/publication

In a list like the module list only the first one would be needed, but with the second you get more functions for the same solution. As I see it, most people would be happy with the first one - most of them only just as happy with the second. The rest would be thrilled about the extra functionality - the rest would not have chosen the solution without it. So there is no doubt that the second solution would be more benefitial to the PostNuke community.

If the first one is easy, why not make it - and learn what more ideas to come - and then create the second as a choise. So we would have both :)

The whole idea of untrusted corrections makes me nervous. The exception being if you allow anyone to do anything, like a Wiki.

In the pnModules example, wouldn't it be best to assign a maintainer to each publication? Then the author or the maintainer can update it. I guess this could be done in Permissions. Being basically lazy though, I'd like to be able to specify the maintainer on the publication itself.

I am in the process of building a document repository for my department at work using pn/pagesetter and the knowledge base example.
* Anyone in the company will be able to read.
* Anyone in the company will be able to submit something to the repository (once untrusted submissions are available).
* Those that belong to the DocMaintainer group will be able to edit. And everyone on my team will have this level of access. This means that we can all help to keep our documentation up to date.

I originally used a Wiki but it didn't support our requirements. Then I considered how to implement a Wiki in Pagesetter. Didn't get very far with that but it sure sounds neat.

On the subject of staging the updates to publications... If this is a requirement, it seems to me that keeping the revisions in a separate table is a bit cleaner. You know that everthing in the "live" table is production-level information. This is something that I would need to turn on/off at the publication type level though. Most of the time I am going to want only one oopy of my documents (no versioning).

Untrusted corrections need of course to be moderated and approved before being available online.



Well, yes, but it requires Pagesetter to maintain an identical database setup for two separate tables. It also depends on a perfect copy from one table to another - probably not a problem, but there's an extra complexity added here - making sure the two tables are in sync.

Both solutions yields another problem - how to keep track of meta data as well as templates! What if a field is removed some day - what should then happend to the old revisioins, and how should they be shown? For now I will ignore the problem.

This is true. There are risks with both options. If the "updated but not approved yet" data is stored in the same table as the current version and if the filtering is not correct we will see a different version or multiple versions of the publication(s).

Staging updates to publications definitely adds a level of complexity to the product.



I see both sides of this issue.
a) In 99.9% of the cases, if we use the current templates to display prior versions of publications no one will care.
b) There will be a very few cases where someone needs to view prior versions of publications exactly as they were created. This requires versioning the the publication type info (meta data) and possibly the templates. That doesn't sound like any fun at all to code. This will probably come from a corporate deployment and it will be a show-stopper for them. But hey, if they like the rest of Pagesetter, they can pay to have that done, right?