On 18 Jul 2007, at 22:34 , Maciej Wisniowski wrote:
I will add this to the zopeproject docs. I wonder:
* Would it help if the 'myzopeapp' package would not be in the top-
level MyZopeApp directory, but in a 'src' directory below
MyZopeApp? Would that make it clearer where to go?
* grokproject actually also creates a "hello world" browser page.
That way there's some initial code there and people might know
better where to go in and change stuff. Would that help? Or would
that be too much unnecessary boilerplate?
For me, second approach is more clear but even simple README.txt,
located at new project's folder, with description of next steps,
should be enough.
The problem with boilerplate README files is that they're never
changes after the fact, therefore making it look like your code has
documentation while in fact it's just the unchanged boilerplate. At
least the code *has* to be changed to make something useful out of it.
2. Is this kind of setup (I mean using zopeproject) supposed to be
used to deploy applications in production environments?
It certainly can be used for deployment, though you'll probably
want to make some changes to the configuration files before you
deploy (rip out the administrator account, deactivate developer
mode, etc.). Again, this is a good question that should be
answered in the zopeproject docs.
Would be nice to have this kind of description, especially
that a lot of people is not familiar with Paste (I think so). For
example I was looking for something like zopectl start|stop|restart. I
don't know so far how to do it (I did not read Paste docs yet - do I
really have to? ;) ).
You shouldn't have to read docs on Paste just to get started. If you
want to actually make use of it (e.g. middlewares via PasteDeploy), I
suggest you do read up on it.
One more thing that is rather about 'death to zope instances' not
zopeproject itself is that that so far it was possible and easy to
have one Zope serving few different apps. With new way seems that
instance is bound to application.
This may be a pain if you have to pay for hosting. Usually there are
serious restrictions to number of long running processes (like
Zope) you may have (e.g. Webfaction hosting).
Aha. How stupid. I'm inclined to suggest to switch to a decent
hosting provider :). A virtual server with root access is cheap these
days.
Then again, WSGI will hopefully give us the possibility to serve Zope
from within Apache, for example, therefore reducing the Zope's
requirements for deployment. I think this model has fitted the
scripters very well, probably one of the reasons why Perl and PHP are
so successful.
Anyway, I have no short-term interest in supporting multiple Zope
applications within the same "instance". Zope 3 was never really
designed to work that way, anyway, because of all the global state
that ZCML defines. (Unfortunately, that global state also makes it
impossible to use two different Zope WSGI applications in the same
Python process...)
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
