Hi Nico > In one of our workflow implementations we made a workflow object which > stores the status of the workflow. The workflow object is linked to the > content element which is in workflow. It is also linked to the users which > should have the workflow in the tasklist. The rights of an user on a content > element is controlled by the editors. We have a tree-like navigation > structure where users have roles on the branches. The content elements are > linked to a node in the tree. The roles define what you can do with a > workflow in a specific status. > Sounds like a good basis to work from.
> The problem with workflow is how you want to keep your site live and change > a content element. If you have a single cloud then you have to make a new > version of the content element and promote the version when apporoved. You > have to make sure that the version does not show up on the live site. You > could do that with the MMBase context security and define 2 contexts. The > edit context and the live context. The anonymous user is only allowed to > read the live context. I'd imagine approval processes would take transcations to a new level. I'm assuming they are kept alive in a session at the moment, possibly the transaction would have to be bound to a workflow state in this situation - committed if approved, rolled back if not, but might propogate another workflow task, with the original data, sending it back to a point in the workflow with corrections required, otherwise rejecting completely. > Duplicating content elements could kill a high traffic site. Another > solution on the version issue could be to create 2 clouds and let them > communicate by rmi. The editors working on one and the visitors watching the > other. On some Broadvision sites I was working on, we used staging tables, so workflow content was effectively completely offline until approval. This was done, simply by appending "_offline" to the table name in the data management objects - tables being a duplicate of originals (or live data), except for one or two new workflow fields. Timestamp information was used to handle multiple instances - the record for the data item in the workflow process was immediately created, along with owner user and timestamp fields, multiple simultaneous edits were dealt with on a first come, first served basis. If another user had edited simultaneously with someone else, the edit post would change the workflow state and lock out other edits - an edit post would return success or failure to the user. > I never have worked with Broadvision and am curious how the workflow works? Broadvision did not have a fixed workflow management facility, merely facilitated the building of workflow systems. Broadvision was usually a big investment, so companies tended to do a lot of development, most of the sites I worked on had a budget of between �3 and �5 million. The layering of objects and object functionality facilitated a particular style of workflow. Typically there were two levels, page level and user level - data was simply offline, so no content concerns. I introduced scenarios with users linked to scenarios with read or read/write flag at page level. A scenario would be a series of pages, so I had a link table with page and scenario id, either read-only or read/write and an order field. Navigation was built on the fly using this table. If I were to venture an opinion, I'd say that there may be a missing layer in your model (for a generic workflow platform) - the one I identified in Broadvision sites (at the lower level) was a simple page/user management layer and I suggested scenarios because it was easy to manage, as well as being a generic dynamic menu management layer, for when did not need workflow, but wanted to target users. The scenario layer was later expanded to link to user profiles/communities and this was by far the most useful change. On the public website, we'd collect bits of info on users (accumulate clicks at various parts of the site, user preferences, etc) and profile the users on that basis. A basic rule system would define which scenarios applied to those users, although these were overridden by user settings specified by the user themselves. I'm of the view that workflow should be driven top-down and should be functional in it's most simple state (sometimes all one wants is page management - a single scenario), becoming more complex until it overlaps and beomes part of data transaction management. At the highest levels, it has the capacity to expand out of role management into a rule based targeting system, where collected data and user preferences dictate process and procedure in it's simplest form and even what the user sees in it's more complex form. Profiling is primarily used in this process - profiles encapsulating other profiles, both data and users being profiled. I hope this helps. Regards Emile
