I appreciate the list members time and patience. I used Zope heavily 2000-2003 but after not writing any code for almost five years this is like starting over. :-)
On Fri, 2008-07-11 at 06:48 +0200, Markus Kemmerling wrote: > You want to restrict the elements of a list to instances that provide > a given interface IMyClass, right? That's exactly what a field's > value_type attribute is for: Thanks. I missed that in the docs about collections. > > is meant to be used in class definitions to declare that a class > itself -- not is instances -- provides a given interface. > I use that and I guess that's why I thought it might do double duty. > I am not sure if I get this. If you set an instance of a mutable type > like a list as an attribute of some other instance described by a > schema, it will be validated, but still remain mutable (finally your > other object only holds a reference to your mutable). It doesn't > matter if it is persistent or not, or if it was copied before. But I > might misunderstand your intention here. As usual a bit of context will help if you'll bear with me. I am implementing a set of healthcare application specifications designed (over almost 2 decades) to maintain semantic context of information across applications and to be implementable in any OO language. There are implementations in Eiffel,Java and .Net. http://www.openehr.org This will reduce the number healthcare data silos since any application in any language can exchange information. The reference model describes broad concepts such as observation,instruction,action,etc along with the required data types and data structures to support them. The 'instances', referred to above, are created as constraints on the reference model in order to define a maximal dataset for ONE clinical concept, i.e. blood pressure. These definitions are parsed from a special purpose language (see attachment) designed to describe the entire semantics of that concept. Since (with my code) parsing one of these and creating the in-memory object takes about .1 - .2 secs. and since an application may use as many as 20 on a screen it is out of the question to do it on-the-fly. My solution then is to pre-store these in a repository in the ZODB as a kind of template. An application can then reuse these by making a copy. My priorities are: 1. To demonstrate implement-ability in Python. 2. Have a platform that can be used to demonstrate and teach the reference model and archetypes in use to a broad audience; physicians, health care researchers, computer science and medical students, etc. 3. Build an interested open source community where 'real' developers can fine tune my code and create wonderful interoperable healthcare applications using the reference model in their chosen language. So, yes I am recruiting developers to what I believe is a good cause project. In the interim I will keep plugging away at. :-) Thanks, Tim -- ************************************************************************** Join the OSHIP project. It is the standards based, open source healthcare application platform in Python. Home page: https://launchpad.net/oship/ Wiki: http://www.openehr.org/wiki/display/dev/Python+developer%27s+page **************************************************************************
openEHR-EHR-OBSERVATION.blood_pressure.v1.adl
Description: application/extension-adl
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users