Forum OpenACS Development: modetp - an ETP modification

Collapse
Posted by Jun Yamog on

Hi

I just would to get some feedback from you guys. Basically modetp came out of a quick hack from ETP. The some functions has slowly been added. The initial modetp was backwards compatible with ETP, but its current state may break ETP. Anyway enough rambling for those of you want to see it in action go to.

Modetp Demo
username: demo@infiniteinfo.com
password: demo

The major changes from ETP are:

  • Each version can be edited rather than reverting and removing all version before it.
  • Different admin UI
  • Ability to manage binary files
  • Does not auto publish pages
  • Templates can be applied on a per application basis.
  • Visual Editor for IE 5.x and above
  • Some other stuff
Stuff that it does not do yet: (I will do this once its hopefully integrated into ETP)
  • Oracle port has yet to done
  • other ETP apps are broken

I would like to thank Luke P for making ETP. Hopefully much of this gets back into ETP. There are still a lot of improvements that need to be done. One of them will be reengineering some of the stuff in ETP. Grouping similar stuff to procs, making more db api, etc.

The visual editor was started by my officemate Mello Capinpin. Hopefully this editor can be used with other ACS packages such as bboard, news, etc. I just ported it to work in OpenACS 4, also if there are any alternative way please let me know. The current relies on IE, it would be better if it runs on IE and Mozilla.

For those who want to get the code get it from here . Just extract it to /packages. This will overwrite ETP files so if you have ETP dont extract it. Install ETP and "HTML Editor". Then mount the 2 application. Dont use the ETP admin as it might do funny things use only the modetp-* files.

I know Dave wants a workflow. It would be great if we can get workflow in ETP. But its must be optional not a requirement as some sites will not need a workflow.

Enjoy and please give your feedback.

Collapse
Posted by David Kuczek on
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.

I think we need to define "workflow". When we are talking about adding workflow to a package, it means using the workflow package to manage the processes. This can all be done behind the scenes. It allows the developer to quickly build a process and the forms to perform that process. It does not mean adding unecessary complexity to an otherwise easy to use application. Or hopefully not, anyway.

I suggest everyone who can get the chance checks out the acs-workflow packages documentation. It if very clear and I think it should be the model for documentation for other packages. Compare it to the documentation for other packages and you will understand what I mean.

I don't want to take over control of ETP either :). I just need certain features for an application I am using and I want to see what would be useful to others also.

Collapse
Posted by Jun Yamog on
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.

Collapse
Posted by Sam Snow on
Be sure to try the visual editor!! Two thumbs up!

Once you have clicked "edit this page" you have the normal code editor showing. To get to the visual editor you need to click "Visual Content Editor" under the "Content" header.

Collapse
Posted by Don Baccus on
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!

Collapse
Posted by Stephen . on
So ETP is the replacement for the CMS package? What does this mean i.e. should no further work be done to CMS, which (mis-)features are to be moved or not from CMS to ETP?
Collapse
Posted by Don Baccus on
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.

Collapse
Posted by Michael Feldstein on
According to the old status doc, the workflow-based version of
ticket-tracker is "destined for the dustbin of history." Is that still
true?
Collapse
Posted by Don Baccus on
Right, because the plain old ticket-tracker is also workflow-based ...
Collapse
Posted by Michael Feldstein on

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

Ah. Then I'm confused but happy.

Collapse
Posted by Vinod Kurup on
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? 😉
Collapse
Posted by Jun Yamog on
Yup there is a lot of cleaning up to do.  But I would like to wait for Luke P's direction and advice.  He has already the code and I have been emailing since I started.  Hopefully we can just have ETP and not modetp and ETP.  Modetp was a real quick hack but it turned out to be something I can learn on.

Also I think ETP and CMS will survive.  Although the real story behind modetp is that.  I need a cms-lite so I took on CMS.  Triming and understanding it after 3 days of coding tried out the ETP way.  After 3 days of coding modetp on top of ETP I have more progress with it than CMS.  So in 2 weeks time I have something running and the rest was just bug fixing and refinements.

Using Mozilla maybe harder but I think it should be done.  I will see if we still have resources to make the Mozilla port.  This involves a lot of Javascript.  Anybody there who is Javascript guru?

As for the workflow I will not be touching that in the meantime but acs-workflow is the only way to go.