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

[yuppie]

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.



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.


Cheers,
	Yuppie