Hi, On 23 September 2012 11:05, Franco Pellegrini <[email protected]> wrote:
>> > I thought of doing this the same way as the data and configuration, that >> > way, if we remove the tile, then we remove all this info too... if we do >> > it >> > with an adapter, then we would need to write additional code so we do >> > not >> > end up with inconsistent info. >> >> You can store it in the same place, even if the API is exposed via an >> adapter. > Right, but what would be the advantage of changing it to be an adapter ? It means you can't break the API incompatibility between c.cover and the more general tiles, and you can use adaptation to add cover-compatibility to existing tiles. >> >> - Why does IBasicTileData have get_* methods? Why not just access >> >> through the tile data API? >> > >> > >> > I don't like to access attributes directly, but to have methods to do >> > it. >> > This way if in the future field names change, or maybe we need to >> > preprocess >> > or whatever the info before returning it (like for instance RichText), >> > you >> > only need to do it in one place. I know this is not very "pythonic", old >> > habits... >> >> This is what property() is for ;-) > > > I know, but i just don't like it very much, it can make the code a bit more > complicated to understand, and i think it isn't much more different of doing > it the way it is done, am i missing some theory behind it maybe ? I think when we write Python, we should follow the prevailing conventions in Python. get_* methods are not very "Pythonic". The theory is that you can start with a simple attribute, and turn it into a property only if you actually need that (e.g. processing on get or set). Being incompatible with conventions for personal aesthetic reasons is not in the interest of the consumers of the code you write. > The idea is you can specify which groups are allowed to edit the tile's > content, so we are not checking specific permissions, just checking if the > user is in the proper group and raising Unauthorized... This is something of an anti-pattern, I think. The Zope security model is based on the idea that you always check permissions, not principals (e.g. users and groups). You then assign permissions to roles, and roles to users and groups. Martin _______________________________________________ Product-Developers mailing list [email protected] https://lists.plone.org/mailman/listinfo/plone-product-developers
