On 4/12/09 12:02 AM, Tim Hoffman wrote:
> Hi Chris
> On Sun, Apr 12, 2009 at 11:55 AM, Chris McDonough<chr...@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
>>> 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
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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -