oship-dev team mailing list archive
-
oship-dev team
-
Mailing list archive
-
Message #01095
Re: Parameters of constructors in datastructure.py
Em 29 de junho de 2010 12:19, Eduardo César <xcesar@xxxxxxxxx> escreveu:
> Hi all,
>
> I am too a bit confused by parameters of constructors of some classes
> in datastructure.py. Its related to the Wagner's question, but in a
> different aspect.
>
Some of classes in data had an super classes that have mandatory attributes.
Take a look at their and you'll find out why classes you are trying to use
had more properties than you think.
>
> Classes Item, ItemStructure, Cluster, Element, ItemTree have a whole
> set of parameters that are not described in the specification
>
> Example:
>
> class ItemTree:
> ...
> def __init__(self, uid, atnodeid, name, atdetails, fdraudit, links,
> parent):
> DataStructure.__init__(self, uid, atnodeid, name, atdetails,
> fdraudit, links, parent)
> ...
>
> It's a bit weird for me(I suppose for you too) a class might be a several
attributes. When I saw classes like that I feel like something wrong, but in
this case could be OK. Inheritance is the way choose by openEHR
Specification to explain the connections between the concepts, mainly
between the archetype layer and the reference layer.
> Why do they have all of those parameters? I could not discern their
> purpose in the way they were made.
>
>
> Another question:
>
> To implement to asHierarchy() method, present in many classes, I have
> to use the Cluster class, so it have to go "up" in the file, before
> some other classes. But by doing this, the code breaks, because the
> ICluster class itself needs other, more "down" in the code class.
>
> Just to remind : Zope interfaces are not Java interfaces. The Zope
interface properties using zope.schema are used to provide documentation and
can provide web interface behaviour. If there's an attribute declaration
that is making problems to you, simply change it to attribute declaration
provided to the Attribute class from the zope.interface module. It's a
simple way to solve, I guess. Interface attribute definitions aren't
important at moment, I think.
Diego, perhaps you can point to me a direction and some advice on how
> you solved the "circular dependency" concerning the History class.
>
Ok. If I can, I'll glad to help. I thought an fast approach as I tried to
explain, but I think we could change after to a better solution.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~oship-dev
> Post to : oship-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~oship-dev
> More help : https://help.launchpad.net/ListHelp
>
--
http://dmpinheiro.net
-----------------------------------
Diego Manhães Pinheiro
Follow ups
References