[Zope-CMF] CMF 2.2.0-beta reminder

[yuppie]

Hi!


Charlie Clark wrote:
> Am 09.12.2009, 19:22 Uhr, schrieb yuppie <y.2009 at wcm-solutions.de>:
>> -1
>> I don't think a write-on-read solution is acceptable.
> 
> Okay. How about on creation?

There are different ways to create type infos. I don't think the class 
constructor should contain any magic that sets computed defaults.

But I would be fine with some kind of wizard in the ZMI that helps to 
create icon and add view URL expressions based on the type info id.

>> I'm afraid any attempt to make this simpler also makes it less explicit
>> and less flexible.
> 
> I'm a big fan of "explicit is better than implicit" but only part of the  
> expression is flexible. The traverser and TypeInfo id are not but they are  
> also not interpolable when the expression is evaluated which goes against  
> the spirit of expressions, I think.

The only part that is not flexible - at least in the use cases I'm aware 
of - is the 'string:${folder_url}/' prefix. The traverser and TypeInfo 
id can replaced by something different.

'string:${folder_url}/addDoc.html' works perfectly if you make sure 
'addDoc.html' returns an add view for 'Document'.

The main reason to use expressions is to interpolate names that can only 
be resolved on runtime, e.g. folder_url.

> BTW. how do addViews cross the CMFCore CMFDefault divide? Shouldn't the  
> traverser be part of CMFDefault?

Type infos are part of CMFCore, so the general concept of add views is 
part of CMFCore as well.

Skins and views are part of CMFDefault.

The traverser belongs somewhere in between. I can't see why it would be 
better to have it in CMFDefault. If you really think it belongs into 
CMFDefault: Why do you think CMFCore's type infos should create add view 
URLs that are especially made for that specific traverser?


Cheers,

	Yuppie