[Grok-dev] BOUNTY! was: Next Step to Bug Resolution???

Tim Cook timothywayne.cook at gmail.com
Thu Dec 18 10:14:23 EST 2008

OOOPS!  I forgot to provide the link to the installation instructions:


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 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*
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.zope.org/pipermail/grok-dev/attachments/20081218/b0d2cbd5/attachment-0001.bin 

More information about the Grok-dev mailing list