[Zope-CMF] Re: RFC: CMF 1.5 Release Plan
Tres Seaver
tseaver at zope.com
Sat Jul 3 13:03:51 EDT 2004
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
More information about the Zope-CMF
mailing list