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

yuppie y.2004_ at wcm-solutions.de
Fri Jul 16 12:49:19 EDT 2004


Hi Tres!


Thanks for your reply.

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?

> 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?

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?

>> 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.

>> 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.

>> 5.) action elements not in sync
>>
>> I guess at least 'apcExport.xml' and 'ticTypeExport.xml' should be in 
>> sync. Permissions should always be a list. See also my "naming 
>> conventions proposal".
> 
> 
> Consistency is a good goal, but a secondary one.  The most important 
> goal is being able faithfully to dump and reload the configuration, 
> against the current form of the tool (backwards compatibility issues 
> will creep in the moment we ship the beta, too!)  I don't have 
> objections to changes which make the exported XML files more consistent, 
> as long as they don't make it harder to export / import the individual 
> files.

At least the fact that apc permissions are not exported as a list should 
be fixed.


Would it be ok if I

1. change permission in apcExport.xml and permissions in 
ticTypeExport.xml to a sequence of permission subelements and

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

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


Cheers,
	Yuppie




More information about the Zope-CMF mailing list