On 4/12/09 12:02 AM, Tim Hoffman wrote:
Hi Chris
On Sun, Apr 12, 2009 at 11:55 AM, Chris McDonough<chrism@plope.com> wrote:
On 4/11/09 11:49 PM, Tim Hoffman wrote:
Ok so pretty much the same as the traditional Zope 3 model.
Are you still using the 'c' based zope.security or built your own. We don't depend on zope.security and there is no C in the BFG security code itself.
On a side note I have got a big chunk of zope3 running on gae (had to gut zope.security and zope.proxy) and plan on revisiting the whole effort looking at bfg, but I would need to revert to zpt because cheetah Chameleon, I think you mean.
Oops yeah! ;)
is dependant on lxml and its no 'c' for me, any suggestions or ideas on the effort involved. (I have zpt running with similiar functionality to zope.app.pagetemplate level rather thatn zope.pagetemplate) with full macro lookups etc.... Malthe has expressed interest in removing the lxml dependency from Chameleon, but I think he needs funding. Others have also expressed an interest in this and we'd probably kick in to a pool of funds towards this if you ever get to a point where it became something you wanted to do. I really don't know how much effort is involved, but for the record, Chameleon only depends relatively shallowly on lxml (mostly for xpath expressions), and removing lxml will make no difference in rendering speed.
ok but I assume it's not too much of a problem to swap out chameleon altogther in the meantime and go back to zpt (unfortunately I don't have money for this project ;-(
Yeah, that's really no problem. As long as you have C-free versions of zope.interface and zope.proxy laying around already (which is really just a matter of preventing those packages' C code from compiling I think), getting BFG running on GAE without Chameleon really just should be a matter of removing the lxml dependency from the setup.py of bfg itself.
Again thanks for the info.
My plan to is to rollout a small site I am building in zope3 on gae, and then go back and do a major refactor on what I have learnt, and look at bfg as the model going forward.
Sounds like a plan... I hope to learn from what you do to get rid of some non-lxml C dependencies we have too (ala zope.interface, zope.proxy, zope.hookable, zope.i18nmessageid, etc); maybe we can fold some of this work into the normal or alternate version of these packages. - C