[Zope-CMF] how to distribute CMF components?

[Jens Vagelpohl]

seb,

a good patterns that is emerging here at DC is to package customizations to
the CMF as separate python products.

take a look at the structure i used for the CMFLDAP package:

http://cvs.dataflake.org/CMFLDAP/

the customization consists of:

- 2 overridden tools (portal_membership and portal_memberdata)
- an additional skins directory for the skins tool

as an added convenience the product has an external method in the Extensions
subdirectory that will automate the replacing of those tools, instantiating
the new skins directory in the skins tool and the juggling of existing skin
paths to include the new skins directory.

jens


On 5/9/01 8:14, "seb bacon" <seb@jamkit.com> wrote:

> Background: I find the Undo interface of the zope CMF slightly
> confusing, and I think my users are even more likely to do so ("what's
> this 'manage_edit' thing?").  So I've hacked up a couple of extra
> methods in the UndoTool so that it
> 
> 1) only undoes the last action
> 2) treats an 'action' as a logically discrete group of transactions
>    (e.g. 'adding a page' is an action, consisting of 3 transactions:
>    metadata_edit, metadata_edit_form, and invokeFactory)
> 3) works out if the next undo is a 'redo' or an 'undo', to make the
>    UI more intuitive.
> 
> This solution only allows the undoing of one action, but I think it
> offers my users most of the benefits of 'undo' with less hassle.
> 
> Question: How should something like this be distributed?
> 
> For starters, I thought I should subclass UndoTool to create a
> SingleUndoTool.  But maybe this is the kind of functionality that most
> users want, and it should be in the core?  Should I post a feature
> request to the collector?  If I make a SingleUndoTool, how can I
> maximise its use to other people?  Should it be treated as a product?
> If there are to be lots of custom tools, perhaps there should be a
> special 'tools download' section on the dogbowl, with generic
> instructions on how to install tools.  I can see this happening with
> Workflows, for example.  But then there's a further problem: tools can
> be uncoupled from the UI, but they don't make much sense without
> context.  Perhaps tools should be distributed with example UI code
> too?
> 
> Just thinking aloud, really.  But if we're to leverage the clean,
> loosely coupled design principles of the CMF to share solutions, I
> think we should make an effort to standardise how this sharing might
> be done.  
> 
> What does everyone else think?  Are there too few third party
> components to worry about this for now?  Is the CMF likely to change
> too quickly for third-party components to have a shelf-life of more
> than 2 months?
> 
> seb
> 
> _______________________________________________
> Zope-CMF maillist  -  Zope-CMF@zope.org
> http://lists.zope.org/mailman/listinfo/zope-cmf
> 
> See http://www.zope.org/Products/PTK/Tracker for bug reports and feature
> requests
>