Congratulations Tim - you are really getting your hands dirty now! Welcome to level 3 (or is it 4?)
Sam
Tim Cook wrote:
(attachments)
Well, right now I feel like that 'I' am at level ZERO! 
But thanks! This has been one of those projects rolling around in my
head for several years. Many things conspired to keep it suppressed but
it feels good for it to actually becoming reality.
It is currently frozen at Revision 19 since I am starting a major
refactoring to solve the circular import issues. This may take up to 2
weeks. If anyone wants to help you don't even have to know anything
about Python. I could use lots of copy/paste work and the instructions
are posted in the development mailing list archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=oship-devel
Cheers,
Tim
Congratulations Tim - you are really getting your hands dirty now!
Welcome to level 3 (or is it 4?)
SamWell, right now I feel like that ‘I’ am at level ZERO!
But thanks! This has been one of those projects rolling around in my
head for several years. Many things conspired to keep it suppressed but
it feels good for it to actually becoming reality.
Congratulations, Tim! =)
It is currently frozen at Revision 19 since I am starting a major
refactoring to solve the circular import issues. This may take up to 2
weeks. If anyone wants to help you don’t even have to know anything
I had to fight the circular import (dependence) issues in the Java implementation from time to time. The last time was that I wanted to use the minimum terminology service component inside the test code of RM core component (all RM classes except EHR and Demographics), but had to give up due to circular dependency. Where do you have the issue in your implementation?
Cheers,
Rong
[moved from the technical list]
I had to fight the circular import (dependence) issues in the Java
implementation from time to time. The last time was that I wanted to
use the minimum terminology service component inside the test code of
RM core component (all RM classes except EHR and Demographics), but
had to give up due to circular dependency. Where do you have the issue
in your implementation?Cheers,
Rong
First of all. Part of the problem is two design decisions I made
because I think that they are important for the sustainability of OSHIP:
A) I want to adhere as closely to the specifications as possible. This
will hopefully reduce users (healthcare app developers) learning curve
and it will make it easier to deal with specification changes in the
future.
B) I want to use the zope.interface package to define class attributes.
This provides a pathway to use all the cool form/widget auto-generation
capabilities to speed up application development. You'll literally be
able to mock up a small application within a few hours. All based on
openEHR infrastructure.
An example might be where CodePhrase is used as an attribute type of
DV_TEXT.encoding or DV_TEXT.language in the same rm/datatypes.text
module. To define the interface for the text module I need to use a
class in the text module implementation. This issue is the reason to
breakup the current modules into specific interface/implementation
files.
The second issue which may be more manageable with delayed imports but
can be more complex in some ways and makes the serializer more tedious
(lots of mapping between class names and ADL output) in cases like
DV_MULTIMEDIA has a thumbnail attribute that is of type DV_MULTIMEDIA
which of course has a thumbnail attribute of DV_MULTIMEDIA, .... While
not an insurmountable issue I do still consider this to be a confusing
design issue and requires some implementation work arounds even though
it isn't mandatory. So, if I implement a Thumbnail class that mirrors
DV_MULTIMEDIA without the thumbnail attribute in order to make
implementation easier. Then I have to be sure that the serializer knows
these things before it creates the ADL for an extract so it can say,
Thumnail == DV_MULTIMEDIA with an empty thumbnail attribute.
These are early days and there may be better ways???
We'll see.
--Tim
Just one point on how serialisers should work - I have written some from
scratch for serialisation and also low-level database interface uses,
and in realistic object structures, you have to do it in two phases:
1. traverse and mark all objects in the 'closure' (reachable by
references, possibly with some intelligence, to stop going into
shared objects)
2. traverse again, processing each object - only if it is marked -
and unmarking it.
A way of handling shared objects (i..e objects referred to by more than
one other object) is needed in the serialiser logic (e.g. see the ADL
manual for how dADL does it). The marking needs to be supported by some
low-level aspect of the language usually. Each language will do this
differently.
- thomas
Tim Cook wrote: