Forum OpenACS Development: modetp - an ETP modification

I just played around with your modetp... The editor is really great. We have been talking about this kind of functionality some time ago on this bboard. I am sure that the future etp will be a huge module.

In my opinion it would be best to have one grand version of etp. If there is anything that an openACS user doesn't need about etp, he should simply be able to deactivate it (like the future workflow) and not to load a modulated package.

Hi Dave,

Yes I am thinking about acs-workflow.  The believe Vinod is the guy that knows a lot about workflow.  Anyway I think I will have to leave workflow to you.  Of course Luke P has the final say since he is the author of ETP.

The best way to implement workflow I think is to make an ETP application that has workflow.  So its like default, news, faq, content w/ workflow.

I am also thinking that ETP be made into more of a service or platform.  Wherein there is a lot of API.  So ETP sits on top of CR then other developers can sit on top of ETP.  Right now modetp is just another application.  So other people can make their own apps.  But at its current state I there are a lot of code that must be moved from default, news, faq and modetp to ETP.  There should be more code reuse.

Anyway I leave it to Luke P to give the final direction since those are just my opinion.

Actually I've learned a lot about workflow, too, recently.  Dave's right that you can use it behind the scenes, which is what I'm doing in the dotLRN events package I've been working on.  Lars left us a fine foundation to build on, and we should talk to him about improvements and tweaking after we get this first release behind us.

It is very important that workflow be integrated into ETP if we want it to grow to become a general purpose CMS.  One thing that workflow gets you is the ability to change it - add or remove authorization steps, etc - without changing the code.  This makes it much easier to tweak something like a CMS to fit the editorial process of an existing  business, for instance.

Also, users get their "stuff" displayed to them in a centralized, "tasks todo" page in the workflow package.  If all packages used workflow to manage tasks then users could visit this one, central place to see what's pending.  "Fix this bug!" "Edit this page!" "Cut this release!" etc.  If you provide custom "panels" (templates) and assign them to your tasks, and drive your package from workflow too, then you can present the same forms to the user regardless of whether they get there from within your package or from the workflow "tasks todo" page.

And the Petri net pictures drawn by graphviz provide excellent documentation.

I would say this is a requirement, not an option, for many potential clients.

I find the idea of releasing an editor that only works with IE distastful for a project like ours, so I agree with Jun that supporting Mozilla would be a very good thing to do.  I'd even put it more strongly than that.  What's involved in supporting Mozilla?

It sounds like Jun still has a bunch of clean-up to do, and of course, the Oracle port, but overall this sounds pretty exciting!

It's not necessarily a replacement for the CMS package.  Those who are working with it have plans to make it more comprehensive, so maybe it can grow to be a replacement package.  It's certainly a very useful package.

Reworking the CMS package's UI would be a major undertaking and currently no one seems to like it well enough to take it on.

Back to workflow ... you don't really want to invent separate workflows tied down the individual ETP applications.  Instead, you want to define some workflows that implement various publishing paradigms that can then be applied to the underlying CR objects by any of the applications.

In other words workflows should be thought of as being more generalized and not tied down to a particular application.

One thing I've been considering personally is to put together some workflows for CR objects, and some Tcl API support for that, that any package using the CR could use.  Not for this release cycle, obviously.

This would allow any CR-based package to make use of one (or more) of the common workflow paradigms.  For instance, I'd love to have one that implements the old "open/closed/wait" style of content submission/approval.  The idea is that you could attach whichever workflow's appropriate for your environment and/or package.  If you need a more complex submission/edit/approval process than the old 3x style mentioned above, you'd just make your package use that workflow.

Right, because the plain old ticket-tracker is also workflow-based ...

Yeah, the workflow-ticket-tracker is a very simple app that was used just to demonstrate how workflow works. Ticket-tracker uses workflow in a more sophisticated way. And despite Jun's statements above, I am unfortunately *not* the workflow expert. 😊 When I ported ticket-tracker, i understood how it used workflow, but i didn't delve into the internals much. I believe DanW ported workflow 4.2 and Neophytos ported workflow 4.3 to PG, so I will hand the "Workflow expert" T-shirts to them (or anyone else that claims it) DaveB? 😉