cubicweb #482289 Business Objects, Interfaces, Adapters, Namespaces [resolved]
We currently have a fairly simple Interface / Implementation model in CubicWeb. We define interface classes and we add the __implements__ statement in business object classes to declare which interfaces are implemented. It works well enough for now but we'll probably hit the namespace bug soon, i.e. two distinct interfaces defining the same method name and an entity implementing both interfaces. (We're already flirting with this problem with the parent() method of entities/IBreadCrumb and ITree). I think ZCA already solves the problem and we've heard quite a few positive feedbacks. It might be worth taking a look at it seriously. Otherwise, something easy to achieve in a few lines of not-so-magic Python is:
class MyEntity(object):
def __init__(self):
self.attr = 12
## IBreadCrumb implementation #################################
class IBreadCrumbs(object):
def parent(impl):
print 'ibreadcrumbs.parent() of', impl.eid
## ITree implementation #######################################
class ITree(object):
def parent(impl):
print 'itree.parent() of', impl.eid
x = rset.get_entity(0, 0)
bc = IBreadCrumbs(x)
print bc.parent() # ==> use the IBreadCrumb.parent() implementation
tree = ITree(x)
print tree.parent() # ==> use the ITree.parent() implementation
I can't remember if Java has a real solution to this problem, we might want to explore that also. | |
| priority | important |
|---|---|
| type | enhancement |
| done in | 3.9.0 |
| load | 2.000 |
| load left | 0.000 |
| closed by | <not specified> |
- cubicweb #615240 turn db code in entity.py into a separated orm
- cubicweb #344874 shouldn't we replace unsafe_execute/execute on session by execute/safe_execute
- cubicweb #933769 Entity cache related oddities
- cubicweb #345050 refactor vreg['etypes'] to vreg['entities']
- cubicweb #1381203 [formfields] not all fields delegate form analysis to their widget
Comments
-
2009/10/19 08:28, written by acampeas
-
2009/10/19 08:49, written by adimascio
-
2009/10/19 09:22, written by acampeas
-
2009/10/20 12:19, written by sthenault
-
2009/10/20 12:52, written by acampeas
-
2009/12/09 08:26, written by acampeas
add commentWould it be possible to know (without having to dig deep into zca) how it would solve this problem (as in: what it would look like with zca) ?
I think the solution consists in making two different adapter classes as in:
class MyEntityAsBreadCrumbs(object): implements(IBreadCrumbs) adapts(MyEntity) def parent(self): return 'ibreadcrumbs.parent() of', self.xxx.eid # later in the code: bc = IBreadCrumbs(x) print bc.parent()So the solution to a namespace conflict lies in splitting it into new ones...
Isn't the alleged problem that of a bad API design ? This is a bit ludicrous as this all happens in our framework, where we are supposed to have full control over this kind of stuff.
A simple solution would be to rename the IBreadcrumbs.parent into breadcrumbs_path (or something). This would make the role of the method much more apparent, but without all the interfaces (or zca) boilerplate.
sometime ago as we discussed about cleaning entity classes api to avoid conflicts with the data model, we concluded that most of the logic currently in those classes should be turned into interfaces and adapter.
And zope.interfaces seems almost perfect for this job. We used it a while ago for narval...
would it be possible to have a look at what it'd be to write entities methods using zope.interfaces ?
isn't it possible to have a discussion on the ml (at least) about this ?