Hi
Just on the zope in gae.
I have been hacking away at getting a core of zope running under gae.
(one example is http://baon.appspot.com/ which was a port of an old
portal_toolkit/cmf 1.0 site I used as an excercise)
I am currently using the following packages
app (completely gutted)
component
configuration
contenttype
datetime
deferredimport
deprecation
event
exceptions
i18n
i18nmessageid
interface
lifecycleevent
location
pagetemplate
proxy
publisher
schema
security
tal
tales
testing
traversing
Though zope.proxy and zope.security have been pretty much gutted.
There is practically nothing in zope.app (basically some scaffold left
to support imports from other packages withouth having to change
packages)
I am also using
peak.util
z3c.form
And had to write my own wrapper for pagetemplates to get closer to
zope.app.pagetemplate
and a gae specific publication (based on DefaultPublication) . I have
manually registered
most of the parts (adapters and utilities) of the packages listed
above. I had to do that to avoid all of the extra dependancies pulled
in by the default zml that just won't work in gae (mainly
zope.security stuff) . For z3c.form I did end up using zcml (to hard
to do all the widgets by hand ;-) but had to remove all of the
permission directives from the class statements (like a said it's all
a bit of a hack at the moment)
It's not pretty ;-) but works.
I plan to revisit repose.bfg as a base for this work, but need to
remove cheetah and go back
to pure python zpt, and get rid of all the lxml depenancies.
I put all of this together manually so far (buildout comes next - now
that I know what I need to do).
One question before I go. I had to replace about 90% of
zope.security (well get rid of it)
what would be the best way of specifying a replacement for a core
package like zope.security rather than just replacing it.
If I wanted to share this work it would be a but confusing to call it
zope.security, and it is a bit much to monkey patch.?
Should I call it something like call it something like
z3c.gae.security and just tell people to install it in zope.security ?
Tim
On Thu, Apr 9, 2009 at 11:05 PM, Tobias Rodäbel tobias.rodae...@mac.com wrote:
Hi,
Shane Hathaway wrote:
Hanno Schlichting wrote:
Wichert Akkerman wrote:
I'ld rather not see a whole slew of extra packagse appear. I also
wonder
how the extra number of packages and increasing size of sys.path
influence performance and restrictions on environments like GAE.
For environments like GAE you don't want setuptools and its magic
to be
part of your application. This is were repackaging your entire app
into
one zipped egg or some other flat structure comes in handy.
Setuptools and eggs are a distribution format from my point of view.
They are certainly not the best way to deploy your applications. The
growing sys.path is affecting performance to some degree in all
deployment environments.
Well, zc.buildout ought to be able to eliminate this concern for GAE
deployment. I haven't tried the recipe below, but it certainly seems
like the right idea.
http://pypi.python.org/pypi/rod.recipe.appengine
I released a new version today. It's a lot easier now to use several
eggs within gae. This test thingy http://zpttest.appspot.com/ uses
zope.interface and zope.pagetemplate plus their dependencies. I'm
planning to release another sample project maybe during easter
holidays. It's much more fun since you zope people cleaned up a lot of
dependencies and unveiled zc.buildout. Thanks!
Cheers,
Tobias
___
Zope-Dev maillist - zope-...@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
