[Grok-dev] grok-martian branch ready for your testing pleasure

David Pratt fairwinds at eastlink.ca
Wed Jun 20 14:35:57 EDT 2007


Hi Martijn. Congratulations. I am interested in seeing what grok-martian 
can bring to the table for regular zope3 without affecting security. It 
might be interesting to modify a regular package to see what things 
looks like this way.

I am curious to see whether this makes things better/faster/easier for 
z3 work and whether benefits can be obtained while still making it 
understandable what is happening with configuration. One thing about 
explicit configuration is that it is what you see (so it is evident when 
there are errors where a problem may lie).

Regards,
David

Martijn Faassen wrote:
> Hi there,
> 
> Summary
> -------
> 
> Your task is to test your application with the grok-martian branch (by 
> checking it out as a 'develop' package in your own buildout) and letting 
> me (through the list) know whether there are any problems.
> 
> The branch is here:
> 
> svn co svn://svn.zope.org/repos/main/grok/branches/grok-martian
> 
> (this will pull martian in as an external)
> 
> The tests all run on my machine (after doing the appropriate buildout). 
> The wiki also works. I want to know whether your code still works.
> 
> Expected problems
> -----------------
> 
> Some expected problems that should be easy to fix for you:
> 
> * you define your own grokker. Check out martian's src/martian/README.tx 
> t for information and look at the existing meta.py in Grok for how to 
> use the new martians. In brief: different base class, method is now 
> called 'grok', and changed parameter order (name, factory are always the 
> first two parameters).
> 
> * you try to import something from grok.util in your code and it isn't 
> there. Instead import it from martian.util. I don't think this should 
> happen unless you define your own grokker or directive.
> 
> * you try to import something from grok.directive in your code and it 
> isn't there. Instead look for it in martian.directive. I don't think you 
> will have this problem unless you define your own directive.
> 
> I didn't provide for backwards compatibility as these problems should 
> occur in very few extensions, and should be easy to fix if they do.
> 
> Why?
> ----
> 
> While I said that I wouldn't get around to finishing Grok's martian 
> integration until weeks from now, I kept running into things I wanted 
> from it in my other work, so I bit the bullet yesterday and finished the 
> integration.
> 
> What does this gain us?
> 
> * to the average Grok developer: Grok will continue to work as before, 
> so very little. However, eventually (we're not there yet):
> 
>   * grok-based zope 3 packages that can be reused inside Zope 3 projects 
> without any worry
> 
>   * some infrastructure to make it easier to test grok-based 
> applications. It becomes easier to grok specific objects or define a new 
> grokker from within a doctest.
> 
> * to the grokker developer: a better documented grokker infrastructure 
> in martian.
> 
> * to the grok core developers: the way is now open for us to start 
> splitting up grok into grokcore.* packages. This should allow us to 
> build better compatibility with Zope 3. If you depend on a grokcore.* 
> package with your own package you get many of the benefits of Grok 
> without Grok turning off Zope 3's security infrastructure.
> 
> * to Python developers: an advanced, pluggable configuration 
> infrastructure in Martian.
> 
> Regards,
> 
> Martijn
> 
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev
> 


More information about the Grok-dev mailing list