[Zope-CMF] Re: [dev] CMFSetup: some questions

[Tres Seaver]

yuppie wrote:

> Thanks for your reply.

You're welcome.  Thanks for checking out the tool.

> Tres Seaver wrote:
> 
>> yuppie wrote:
>>
>>>
>>> 2.) default profile
>>>
>>> The default profile seems to be CMFDefault data, while it is not 
>>> completely in sync with CMFDefault.
>>>
>>> Shouldn't this profile live in CMFDefault and be in sync?
>>
>>
>>
>> The default profile is intended to replace (eventually) everything in 
>> CMFDefault.Portal.PortalGenerator.  As I said above, moving the 
>> "configuration / setup" logic out of the product seemed attractive to 
>> me at the time.  Over time, I would like to see CMFDefault become 
>> simpler, declaring pretty much only the "stock" content classes (I 
>> think the membership stuff should move out into a separate product).
> 
> 
> 2.1) Fine. But wouldn't that mean to move also the skins out of 
> CMFDefault? I guess you don't want to add the skins to CMFSetup? Do we 
> need a new package for default profile and skins, something like CMFDemo?

The "site" skins (e.g., 'main_template', 'login_form', etc.) would 
likely move out, while the content-specific ones (e.g., 
'document_edit{,_form}', etc.) would stay.

As I said, I would prefer to have all the membership-related things move 
out into a CMFMembership product.

All this is post-1.5, of course.

>> I envisioned third-party products which did little more than register 
>> new profiles and skin directories (e.g., the original "PloneSkin" 
>> product would have been a good fit).
>>
>>> What would be necessary to use that profile also for site creation?
>>
>>
>>
>> Any product will be able to register one or more profiles.
> 
> 
> Had a second look at CMFSetup. Found 'registerProfile' and the 
> 'Configured CMF Site' factory. Cool!
> 
> But this leads to new questions:
> 
> 2.2) Why doesn't the Setup Tool 'Properties' tab have a select field 
> like the add form, showing the registered profiles?

It is currently just an input field;  I never got back around to 
updating it once I added the profile registry.

> 2.3) How would this work with add ons, like CMFCalendar? Their profile 
> would just contain modifications to an existing site, right? Before I 
> dig deeper in the code: Are available import / export steps those of the 
> current profile or those of all the profiles ever selected?

To answer the last, only those in the current profile.  You should be 
able to snapshot the profile, and then alter its import / export steps 
if needed.

I don't think add-on products would register profiles.  They could 
export handler functions for their tools, including sample profile 
stanzas, and then let the profile owners add them (or not).

Basically, a product which defines a profile is "tail-end Charlie" in 
the dependency chain to every product it uses.  I would very much like 
to break up dependency cycles where possible.

>>> 3.) export_steps.xml
>>>
>>> Why is 'export_steps.xml' part of a profile? Currently I have to load 
>>> the default profile to be able to export something or make a snapshot.
>>
>>
>>
>> It is a kind of chicken-or-egg problem:  until you have loaded a 
>> profile, you don't know what export handlers are available.  I was 
>> avoiding (because I had seen it in the earlier client-driven version) 
>> the complexity of a model where products registered free-standing 
>> export handlers;  dealing with conflicts among them was too painful.
> 
> 
> Well. I had expected a handler registry. But sounds like you had your 
> reasons to implement it the way it is.

A profile represents a set of policy choices.  I am hopeful that 
defining alternatives will get simpler once profiles are in widespread use.

>>> Detail Questions:
>>> -----------------
>>>
>>>
>>> 4.) lists in xml
>>>
>>> Sometimes lists are stored in attributes using values like::
>>>
>>>     ','.join( action[ 'permissions' ] )
>>>     ' '.join(info['roles'])
>>
>>
>>
>> That could probably be regularized.  I prefer the space-delimited 
>> version (because it follows the pattern of the XML IDLIST) but 
>> permisison IDs can have spaces embedded in them (actually, role names 
>> probably can too).
> 
> 
> Seems the 'space-delimited' pattern doesn't work here.
> 
>>> Sometimes they are stored in subelements. Does that follow any policy?
>>
>>
>>
>> For "simple" lists of strings, subelements seem overkill.  OTOH, I 
>> have heard lots of complaints from XML-centric about the 
>> "attribute-heavy" nature of ZCML.  If there is any chance that the 
>> information is (or might become) richer than a single string, then 
>> subelements are an obvious win.
> 
> 
> I would prefer subelements over comma-delimited attributes.

"More XML-ish" is one reason to go there.

> Would it be ok if I
> 
> 1. change permission in apcExport.xml and permissions in 
> ticTypeExport.xml to a sequence of permission subelements and

OK

> 2. rename 'action_expr' to 'url_expr' and 'condition' to 
> 'condition_expr' and

OK.

> 3. update the default profile with a current CMFDefault export?

Yes.

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