Tarek Ziadé wrote:
Hi,
afaik, there are 3 products at this time for collaboration for Plone, one of
them (GrufSpace) is maintained by us (Ingeniweb). Before we decide wheter to
port it to Plone 3 or to help working on another one, I would like to know
what is the status for TeamSpace and ATWorkgroups at this time ?
There is also borg.project, which I wrote and use (and quite like for
its simple and minimalist approach).
I've seen some '*plone3*' branches in teamspace but it seems that two of
them are active. I have also asked a few people, but I totally ignore what
is planned or if something is planned in plone itself.
my guess is that we could come up with a unique product
I think that Plone 3 has afforded us some conveniences that mean some of
the things Teamspace for Plone 2.x had to do are no longer necessary.
PAS + adapter-based local role management (as is done in borg.localrole,
which is PLIP'd for Plone 3.1 and which borg.project depends on) is a
big one. Better use of events also helps a lot.
I'd personally like to see this being factored out into components as
much as possible. Teamspace was just way too much code for me when I
last looked at it and discovered my needs diverged a bit, even though it
is mainly a "framework" type product. borg.project may be too simple for
some people, but then I think we should push the different bits out into
separate and re-usable components.
At the end of the day, it mostly comes down to:
- a local workflow (borg.project ships with a workflow policy, and has
an event handler that uses CMFPlacefulWorkflow to set it up in a team
workspace - both of these could be factored out, though they're pretty
trivial)
- a special TeamMember role used in this workflow is given to project
members (this is done via the borg.localrole PAS plug-in; borg.project
provides the appropriate adapter for a policy that just gives team
members this role)
- possibly, per-project settings for addable types (if you want to do
this in a granular way, you need to mess with add permissions;
borg.project has that code in a utils module, and it's not pretty -
could be factored out, but I'm not sure this is something everyone would
need)
- some project metadata (this is likely to be implementation-specific
anyway, so we want to make it easy to create your own schema or use an
extensible schema implementation)
As for GrufSpaces, I wonder if maybe it's better to put the effort into
migration than upgrades, but then I don't know the product well enough
to know for sure.
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
