[Zope-CMF] Re: RFC: CMF 1.5 Release Plan

[Tres Seaver]

yuppie wrote:
> Hi!
> 
> 
> Tres Seaver wrote:
> 
>> I would like to propose the following release plan for CMF 1.5:
>>
>>   - Release CMF 1.5alpha early next week (likely Wednesday), and
>>     encourage    sumbissions to the CMF collector.
>>
>>   - Have a CMF bug day next Friday (7/9) to close issues for the beta.
>>
>>   - Release CMF 1.5beta ~Friday, 7/16.
>>
>>   - Release CMF 1.5final ~Friday, 7/23.
> 
> 
> +1
> 
>> I believe that almost all the feature work called out in my roadmap
>> posting[1] is now done;  the setup tool could still use additional
>> handlers, but is already useful for many of the tasks currently done
>> by the PortalGenerator.
>>
>> Comments?  Objections?
> 
> 
> 
> 1.) UID generator tool and references machinery
> 
> Some backported code from Archetypes was checked in on the 
> at_reference_backport branch, but I don't think this is ready to be 
> merged. While there was consensus that tools like that should become 
> part of CMF, there was no discussion about the best implementation.
> 
> An alternative to the Archetypes code would be a solution based on
> <http://cvs.sourceforge.net/viewcvs.py/collective/CMFUid/>,
> but I guess this should be discussed as part of the 1.6 roadmap discussion.

I'm fine with deferring this feature.

> 2.) CMFDefault ZPT Skin
> 
> Before the CMF 1.5 branch is created I'd like to do some ZPT Skin 
> consolidation:
> 
> 
> - About 90% of the code used by the Basic (ZPT) skin lives meanwhile in 
> the "zpt_" layers. I'd like to remove the dependency on "topic, content, 
> generic, control", copying the files still used by the Basic skin to the 
> corresponding "zpt_" folders. While this adds some redundant files, I 
> think it would reduce complexity quite a bit.
> 
> 
> - In CMF HEAD I started adding scripts that contain all the logic 
> necessary for one template. While I still believe this is the Right 
> Thing to do, I'd like to rearrange the code:
> 
> To avoid renaming templates, right now the scripts are called from the 
> head of the templates. This is a hack, calling the template at the end 
> of the script is much more straight forward.
> 
> 
> An example:
> 
> The 'edit' Action of Document is document_edit_form. Right now this is 
> the template document_edit_form.pt. This template calls 
> document_edit_control.py to do the logic stuff and the actual controller 
> is document_edit.py.
> 
> I'd like to rename them like that (in the file system, the suffixes are 
> cut off by DirectoryView):
> document_edit_form.pt -> document_edit_template.pt
> document_edit_control.py -> document_edit_form.py
> document_edit.py -> document_edit_control.py
> 
> (document_edit_control.py just exists in HEAD and document_edit.py isn't 
> compatible with the old document_edit.py anyway)
> 
> After that change document_edit_form would be the script 
> document_edit_form.py. This script would call the controller 
> document_edit_control.py to change the Document and 
> document_edit_template.pt to render the return values.
> 
> 
> While this is disruptive regarding CVS history, it should not be less 
> backwards compatible than the current code. Names like 
> document_edit_form, newsitem_edit_form or folder_contents would still 
> return the expected result.
> 
> 
> Hope this was clear. If there are no objections I can do these changes 
> until Wednesday.

+1 from me.  We will probably need to add something to INSTALL.txt to 
explain what people who have customized '*_edit' and '*_edit_form' need 
to do to synch up.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com