Based on private responses I have received I would like to clarify some things.
I fully realize that people have their days jobs. So do I. I do not get paid to work on this project. Secondly, I am a ZCA user. I am a Python tinkerer, not a programmer. It seems to me that it would take me days to contrive a mockup of this situation so that there is a live demonstration of this error outside of my project. I believe that it would take an experienced Python/Zope developer no ore than 1-2 hours to install my application, see the problem and provide a fix. There is an explanation of how to exercise the problem as well as how to apply my suggested fix here: http://www.openehr.org/mailarchives/ref_impl_python/msg00406.html The pertinent part is the last 4 paragraphs and it is copied below for convenience. ************************************************************************ I will later commit an update that fixes two errors he found. I will also include a new zope.schema._filed.py file that correctly processes the multi-level Object field calls that we make. I have no idea when the Zope gurus will be updating zope.schema But I know this fix works for our needs. It will be in the docs directory and named as _field.py.oship To see the problem that exists in the current _filed.py you can start your server and verify that you can go to http://localhost:8080/oship/archetypedetails and verify that you can see the archetype details. In your terminal window you should see that there are no errors reported. Stop your server and go to oship/km/openehr/ehr/cluster/checklist_item_general.py and around line #75 and uncomment the self.parentArchetype assignment. Now start your server and go to the link above. You will get a server error and in your terminal window you'll see that you have a WrongContainedType error. Stop your server. Replace _field.py in you zope.schema egg directory (rename your original first) with the _field.py.oship Restart your server and you will see that it now correctly processes the multi-level Object fields. If you want more details about this then please see the bug report I filed on Launchpad https://bugs.launchpad.net/bugs/301226 ************************************************************************ This issue is such a huge frustration for me that I am offering a bounty of 100USD out of my personal pocket to the first person that solves the issue, gets it committed to a published zope.schema egg and included in the standard Grok distribution. It seems to me to be a reasonable (though not extravagant) amount since most of the trouble shooting has already been done. Thanks, Tim On Thu, 2008-12-18 at 08:35 -0200, Tim Cook wrote: > Hi All, > > I have had an issue on the table for months. I started a dialog about > it here: > > http://mail.zope.org/pipermail/zope3-users/2008-October/008215.html > > The thread was interesting, helpful and did lead me to find an error in > some schema definitions because of a misunderstanding of the required > attribute. But that had nothing to do with the problem. > > It was first thought that it was a nasty, empty error report. After > some investigation I discovered that it was an error that shouldn't be > an error. Once I determined what I thought was the cause and a possible > fix I posted a bug report on Launchpad > > https://bugs.launchpad.net/zope3/+bug/301226 > > So here we are. I have a possible solution and the only comments I get > from the Zope Community are private emails (yes plural) asking me if > anyone is working on this issue. I have to say that as far as I can > tell; no. At this point I would be happier if someone just told me why > my fix might negatively affect the other schema field validations. > > Now I realize that I must be the only person in the entire world to > exercise zope.schema this way. BUT! It should work or it should be WELL > documented that you cannot have cascading attribute=Object(IMySchema) > definitions. > > The description of the project is here: > http://www.openehr.org/wiki/display/dev/OSHIP+Developer%27s+Wiki > > This is a rather major project. See: http://www.ohloh.net/p/oship for > some metrics. We have just received three years of funding from the > Brazilian government to complete the platform and develop an > Epidemiological decision support system on top of it to improve the > recognition of syndromic outbreaks. > > Right now the hardworking core open source team understands that we need > to replace zope.schema._field.py with our own to make it work. But when > the project is ready, in a few months, for healthcare application > developers worldwide to start using it. It may be a hard sell to say; > "Yeah we use the really cool, robust, well tested and trusted > application server called the Zope Component Architecture because it > really shows the strengths of the open source development process. Oh, > by the way, after everything is installed you have to replace a core ZCA > file with the one we provide you in order to make it actually work." > > Doesn't sound very professional to me and it should be embarrassing to > the Zope Community if that has to happen. > > Thank you for reading this long posting. I hope someone delivers me a > Holiday package in the form of a fixed zope.schema package. :-) > > Cheers, > Tim > > -- Timothy Cook, MSc Health Informatics Research & Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ************************************************************** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* **************************************************************
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
