I've looked over the notes about the Portal Toolkit, have just joined the zope-ptk mailing list, and have a few thoughts. (Still have to read over the back archive, though...) * I find it strange that members are able to publish content at all. For most of the portals I can think of -- Yahoo, My Netscape, etc. -- membership means you have access to various features that run off scripts or databases, and you have some sort of customized display. The set of people who publish content is much, much smaller than the set of all members. Zope.org and community discussion forums are the only cases I can think of where members publish content, and only on Zope.org do people see anything like a management screen. In essence, I'm wondering if Members should have no content management capability at all, and their management capability given to some class intermediate between Member and Contributor. * Would it be possible to generalize the model of creating objects which get approved by a manager, so that you have almost workflow-like features. Looking at the PTK from the point of view of the MEMS Exchange, we'd be interested in having more complex transitions, and transitions that can be triggered by different sets of people. For example, our workflow would look like this: * Member creates a Run object * An MX staff member looks at the Run, makes some comments, and bounces it back to the member, who revises it. * MX staffer looks at the run again, and approves the revised version. * 3 other Members with a certain role look at the run and approve it. Various other people get notified about this. The general abstraction is that there can be an arbitrary set of states, and some arbitrary criterion must be met before transitioning from one state to another, instead of only 2 approved/not approved states. This is obviously more complicated, and probably too ambitious for the first version, but it could make the PTK a useful foundation for intranet applications, where you'd embody the way your business works in Python code. BTW, I just re-read "Philip and Alex's Guide to Web Publishing" recently; highly recommended. Chapters 2 and 3 are especially applicable to the PTK, and chapter 13 is also worth reading for Zopers. It's online at http://www.photo.net/wtr/thebook/, but it's still worth buying a copy. -- A.M. Kuchling http://starship.python.net/crew/amk/ We tend to idealize tolerance, then wonder why we find ourselves infested with losers and nut cases. -- Patrick Hayden
----- Original Message ----- From: "Andrew M. Kuchling" <akuchlin@mems-exchange.org> To: <zope-dev@zope.org> Sent: Wednesday, January 19, 2000 3:44 PM Subject: [Zope-dev] PTK thoughts
* I find it strange that members are able to publish content at all. For most of the portals I can think of -- Yahoo, My Netscape, etc. -- membership means you have access to various features that run off scripts or databases, and you have some sort of customized display. The set of people who publish content is much, much smaller than the set of all members. Zope.org and community discussion forums are the only cases I can think of where members publish content, and only on Zope.org do people see anything like a management screen.
This is really site-dependent. I could see an Intranet manager really going gaga over these features. I think people will want to pick and choose what people can do and what interface they would use. On byproducts.com, we'll want people to submit news items (and maybe some other custom objects), but nothing else. We may wrap the process in our own wizards that are tailored to what we do.
The general abstraction is that there can be an arbitrary set of states, and some arbitrary criterion must be met before transitioning from one state to another, instead of only 2 approved/not approved states. This is obviously more complicated, and probably too ambitious for the first version, but it could make the PTK a useful foundation for intranet applications, where you'd embody the way your business works in Python code.
This does sound really useful, and much trickier to implement. Something else that would be useful is something like Frontier's callback mechanism. I honestly haven't installed and run Frontier, so I can't talk to specifics about how their implementation works. But, the idea is that there are hooks that allow you to make something happen when something else happens. (So, rather than a hardcoded send email to <blah> when someone contributes content, you could make a method that performs whatever actions you feel are necessary when someone contributes content.) Again, the callbacks are probably a bit much for the first go, but it's always good to keep the future in mind when building something new. Kevin
participants (2)
-
Andrew M. Kuchling -
Kevin Dangoor