oship-dev team mailing list archive

[Luciana Tricai Cavalini <lutricav@xxxxxxxxx>]

Hi all,

Let me try to say something about what I've heard from Tim about this 
"circular importing" problem.
The fact is that, so far, no Zope application development had to deal 
with such a complex hierarchy as the implementation of the openEHR 
specifications.
Tim has discussed it over and over again on the Zope and Grok 
developer's lists and they often told him that OSHIP was "overengeneered".
This is a lack of understanding about the specific complexity of 
healthcare information, and especially how multilevel modeling has to be 
implemented for healthcare, which is the best (only?) way to deal with 
the complexity of healthcare information.
Despite the fact that ZODB solves the persistence problems that all 
other openEHR implementations seems to struggle with, fact is that 
nodoby in the planet have ever implemented something so complex in 
Zope/Grok as OSHIP, as far as we know.
Thus, dealing with those "circular import" problems is still work in 
progress for us.
So, yes, Sergio, as far as I know, the current configuration is the only 
solution Tim found.
I am not sure about how detailed this whole circular import problem and 
its solution is described in the OSHIP developer's guide, but we need to 
take a look.
We have Zope/Grok experts in the project now; this is something that I 
think they could contribute to. I am sure Tim would appreciate that. Not 
to mention the improvement to the project as a whole.

Cheers, Luciana.


Sergio Miranda Freire escreveu:
> Hi Eduardo,
>
>  
>
> Ever since Oship began, Tim has been complaining about this kind of 
> problem. In the first versions, he had arranged all classes in 
> separated directories and files, according to its package structure. 
> Later for reasons that I ignore he has moved to the current 
> configuration. He had to change the schema of some attributes in order 
> to avoid the problem you have just mentioned. In this case, parent in 
> IEvent is defined as being an IObjectRef. Possibly this may happen 
> somewhere else. This was the solution Tim found. I don´t know if there 
> is an alternative. Maybe it is another case to go into the 
> implementation guide.
>
>  
>
> Cheers,
>
>  
>
> Sergio
>
>  
>
> *De:* oship-dev-bounces+sergio=lampada.uerj.br@xxxxxxxxxxxxxxxxxxx 
> [mailto:oship-dev-bounces+sergio=lampada.uerj.br@xxxxxxxxxxxxxxxxxxx] 
> *Em nome de *Eduardo César
> *Enviada em:* sábado, 6 de março de 2010 01:44
> *Para:* OSHIP-Dev
> *Assunto:* [Oship-dev] Egg and chicken
>
>  
>
> Hi,
>
> In datastructures.py, in the class IEvent, the attribute "parent" 
> needs to be defined as of type "IHistory".
> But there is a catch because the class IHistory has some attributes 
> that are of type IEvent.
>
> If I try to define "parent" with the correct type, the interpreter 
> complains that IHistory is not defined yet. If I exchange the order of 
> the classes, the interpreter complains that IEvent is not defined. 
> Right now, "parent" is defined of being of another type, for things to 
> work.
>
> I am wondering how I can solve this... someone has any hints?
>
> Cheers
> Eduardo
>
>
> --
> Esta mensagem foi verificada pelo sistema de antivírus e
> acredita-se estar livre de perigo.
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
>   

--
Esta mensagem foi verificada pelo sistema de antivírus e
acredita-se estar livre de perigo.