OOOPS! I forgot to provide the link to the installation instructions:
http://www.openehr.org/wiki/display/dev/OSHIP+Installation
--Tim
On Thu, 2008-12-18 at 13:00 -0200, Tim Cook wrote:
> 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
