Re: [Zope3-dev] RFC: zopeproject
On Thu, 2007-07-26 at 23:17 +0200, Philipp von Weitershausen wrote: 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. Hmm. Perhaps both sets of requirements can be satisfied by generating a REPLACEME (or RENAMEME, or EDITME) file with the boilerplate in it. That should still help a newbie get things going while making it clear that it is not (yet) actual documentation for the new code. - Michael signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
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
Re: [Zope3-dev] RFC: zopeproject
Philipp von Weitershausen wrote at 2007-7-18 22:59 +0200: On 18 Jul 2007, at 21:13 , Dieter Maurer wrote: ... I prefer the standard approach: I see a framework -- Zope and a large number of application components that plug themself into the common framework. The application, in fact a complete collection of mini-applications is configured via objects in the ZODB and can be extended TTW. Right. This is what Martijn Faassen aptly calls the Zope 2000 development model. And it's probably about the farthest away from working together with other Python web frameworks I agree with this. and toning down Zope for an easier entry. But, Zope is quite easy on entry. I expect that the traditional Zope-the-application was easier to install and to build applications with than your new approach which requires: * paste * WSGI * zopeproject * the application package * one instance per application True, experts can combine different Python web frameworks -- but what part of the Zope audience will need this? True, Python experts can be more economic with their knowledge. But, it appears the things become more difficult for non-experts. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
On 7/19/07, Dieter Maurer [EMAIL PROTECTED] wrote: But, Zope is quite easy on entry. Zope2, yes. Zope3? Not at all. Will modularizing Zope 3 make it easier for newbies? Not really, but with zopeproject or similar it shouldn't be more complicated either. In fact, the installation process might end up being simpler: Compare: wget http://www.zope.org/whatevah/Zope.tgz tar xvfz thetgz ./configure make make install make instance directory With: easy_install zopeproject zopeproject directory cd directory bin/buildout Or something similar to that. Doesn't really look more complicated to me. :-) Sure, it uses paste and stuff, but you don't have to know about that to use it. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
On 19 Jul 2007, at 19:15 , Dieter Maurer wrote: and toning down Zope for an easier entry. But, Zope is quite easy on entry. To some, probably many, it is easy. At first. Then they discover the limits of TTW development and hit the wall of having to learn this completely new and different way of doing Zope development (products instead of TTW). I also know a fair number of people who were simply so confused by this ZMI thing and the whole concept of TTW development (mostly because it's so different than *anything* else out there, and they couldn't use their favourite tools) that they swore never to do anything with Zope. They didn't even get to the good stuff (filesystem-based development). I expect that the traditional Zope-the-application was easier to install and to build applications with than your new approach which requires: * paste * WSGI These two are not only used by many other web frameworks, they're also documented by them. That means we can share not only code and knowledge but also documentation efforts. Having standards like these two is good. Look at Java. The Servlet or Portlet APIs are probably not the prettiest ones, but sure everybody who ever has to do anything with them will find tons of docs on them. And s/he will be able to use that knowledge, once gained, pretty much everywhere. * zopeproject * the application package * one instance per application True, experts can combine different Python web frameworks -- but what part of the Zope audience will need this? A great consequence of WSGI are middlewares. They're general purpose applications that plug between a server gateway and a WSGI application, be it Pylons, TurboGears or Zope. These are not really frameworks, but more filters that are easy to re-use. In my talk Zope on a Paste at the DZUG and EuroPython conferences, I've demonstrated a number of general purpose middlewares that are completely third-party to Zope. They include simple things like logging and gzipping as well as very useful things like interactive debugging and XSLT-based theming. And the best thing is that they can be plugged in by a mere 2-4 lines of configuration. So basically they're useful and easy to use. I think *lots* of people in the Zope audience will find them useful. At least the audiences both times I've given the talk seemed to welcome the idea quite a lot. True, Python experts can be more economic with their knowledge. But, it appears the things become more difficult for non-experts. In a blog post [1] that I wrote a while ago, I've collected my thoughts on why I think TTW development is a failed model, *especially* for beginners. Instead of posting these thoughts here, I'll simply link to it and invite you to read it. In a follow up to that post [2], I was able to report proof, so to speak, that the standard, down to earth Python approach (in the form of Grok) actually fitted people's brains much better. It fitted so well that we had people contributing to Grok that hadn't worked with Zope3 or Grok at all a few months or even weeks before that. At the EuroPython sprint last week, we could again observe the same happening. [1] http://www.z3lab.org/sections/blogs/philipp-weitershausen/ 2007_03_27_meet-grok-successor [2] http://www.z3lab.org/sections/blogs/philipp-weitershausen/ 2007_04_19_why-zclasses-dead-why ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
On 19 Jul 2007, at 22:35 , Lennart Regebro wrote: On 7/19/07, Dieter Maurer [EMAIL PROTECTED] wrote: But, Zope is quite easy on entry. Zope2, yes. Zope3? Not at all. Will modularizing Zope 3 make it easier for newbies? Not really, but with zopeproject or similar it shouldn't be more complicated either. That's *exactly* the point of zopeproject. You get more for the same price :). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
On 18 Jul 2007, at 19:25 , Kent Tenney wrote: on my W2K machine zopeproject MyZopeProject fails because I don't have Visual Studio installed and it wants to compile extensions for ZODB Right. Something seems to depend on ZODB 3.9.0-xyz now and we have no binary for that (yet). Sadly enough, I recently asked Jim to make Windows eggs and they've all become useless because at least half of the packages now have newer releases (which buildout insists on using). I've heard that mingw can substitute, but I've never succeeded in configuring it. Well, I managed to install it (you need cygwin, then install the gcc- mingw-core package from the 'devel' section). And with 'python setup.py build -c mingw32', it seems I can even build Windows eggs, though I can't get them to work. I get some a DLL error (Access denied.) What's more, there seems to be now way to tell zc.buildout to pass the '-c mingw32' option to setup.py when building eggs. I wonder, if done correctly (and I believe some people, e.g. Andreas Jung, have managed to get mingw to build binary eggs for them), are mingw-based eggs any worse than Visual C ones? If not, then there's a good chance that we can actually get a setup for Windows people that won't require Jim or Adam having to build Windows eggs all the time. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
On Jul 19, 2007, at 6:46 PM, Philipp von Weitershausen wrote: On 18 Jul 2007, at 19:25 , Kent Tenney wrote: on my W2K machine zopeproject MyZopeProject fails because I don't have Visual Studio installed and it wants to compile extensions for ZODB Right. Something seems to depend on ZODB 3.9.0-xyz now zope.app.keyreference 3.5.0dev xxx. stick to the 3.4 line to keep away. and we have no binary for that (yet). Sadly enough, I recently asked Jim to make Windows eggs and they've all become useless because at least half of the packages now have newer releases (which buildout insists on using). (Well, not if you give it constraints.) Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
Am Mittwoch, 18. Juli 2007 01:13 schrieb Philipp von Weitershausen: Feedback As much as I see the library-driven approach replace the instance approach, I see zopeproject as the way to get started with an application instead of mkzopeinstance. I would like to ask everyone who's interested in checking it out and give feedback, both on these ideas and on zopeproject specifically. I personally like the idea - it seems that this may lead to a faster setup of a zope-based package. I am no Zope3 expert but here are just my 2 cents: - Please carefully weight boilerplate code against black magic: For newbies, the generated code should on one hand be easily understandable, which means that there is no code in it that requires deep understandings of Zope3 internals. On the other hand, black magic should be avoided, as such constructs are pitfalls later on. - If I understand this right, this is also a server-centric against application-centric issue. In your case, it's probably easier to get a single Zope3-based application running, but will it also be easy to instantiate a Zope3 server with multiple, different applications on it? - Please don't forget about Grok in this approach, as the simplicity of Grok fits to a fast zope3 package setup. Perhaps a zopeproject --grok would be a good idea. - How much work is it to implement this and how do you estimate the timeline? Best Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
Feedback
As much as I see the library-driven approach replace the instance
approach, I see zopeproject as the way to get started with an
application instead of mkzopeinstance. I would like to ask everyone
who's interested in checking it out and give feedback, both on these
ideas and on zopeproject specifically.
Maybe it is too fast for these questions but these are ones
I had just after trying zopeproject:
1. What should I do after creating project?
Where should I start writing my code? In one of folders created by
zopeproject or
maybe I'm just supposed to create my own folders and put them in
pythonpath?
2. Is this kind of setup (I mean using zopeproject) supposed
to be used to deploy applications in production environments?
3. Does this work with workingenv? While trying to
install zopeproject with active workingenv I get:
#---
(env1)[EMAIL PROTECTED]:~/workingenvs/env1$ zopeproject newone
Enter user (Name of an initial administrator user): blablabla
Enter passwd (Password for the initial administrator user): blablabla
Enter eggs_dir (Location where zc.buildout will look for and place
packages) ['/home/pigletto/buildout-eggs']:
/home/pigletto/workingenvs/env1/buildout-eggs
Creating directory ./newone
Downloading zc.buildout...
Invoking zc.buildout...
Couldn't find index page for 'zope.app' (maybe misspelled?)
No local packages or download links found for zope.app
error: Could not find suitable distribution for
Requirement.parse('zope.app') (--always-copy skips system and
development eggs)
While:
Installing.
Processing develop directory '/home/pigletto/workingenvs/env1/newone/.'.
An internal error occured due to a bug in either zc.buildout or in a
recipe being used:
AssertionError:
(env1)[EMAIL PROTECTED]:~/workingenvs/env1$
#---
without workingenv this works.
--
Maciej Wisniowski
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
On 18 Jul 2007, at 11:22 , Hermann Himmelbauer wrote: - Please carefully weight boilerplate code against black magic: For newbies, the generated code should on one hand be easily understandable, which means that there is no code in it that requires deep understandings of Zope3 internals. On the other hand, black magic should be avoided, as such constructs are pitfalls later on. Have you actually taken a look at the boilerplate (application.py specifically)? It's very little IMO. I suppose it could use a few more comments, but even now I think it's pretty clear what it does. If not, we need to document it better or change it. This is why I wanted you guys to check this out. - If I understand this right, this is also a server-centric against application-centric issue. In your case, it's probably easier to get a single Zope3-based application running, but will it also be easy to instantiate a Zope3 server with multiple, different applications on it? Running multiple different applications within one process is not my goal. It's also very difficult to do due to the global state that we keep in our component registries (different apps will likely conflict). If I would want to support this at all, I would probably recommend creating two entirely separate WSGI applications which would be mounted to specific URL paths using PasteDeploy's composite-app. It is already possible, for example, to run a Zope app and a TurboGears2 app within the same server process. - Please don't forget about Grok in this approach, as the simplicity of Grok fits to a fast zope3 package setup. Perhaps a zopeproject --grok would be a good idea. zopeproject is heavily influenced by grokproject. In fact, I have a branch of grokproject that re-uses most of zopeproject's facilities (I have posted a message to the Grok list announcing this branch a few days ago already). I don't think we'll have to let grokproject die in favour of zopeproject. grokrpoject will simply be a small shim over zopeproject. - How much work is it to implement this and how do you estimate the timeline? Not sure whether I was being imprecise or whether you simply haven't read it all, but all of this is already implemented and fully functional. I actually want you guys to *try it out* for feedback. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
On 18 Jul 2007, at 12:26 , Maciej Wisniowski wrote:
Maybe it is too fast for these questions but these are ones I had
just after trying zopeproject:
1. What should I do after creating project?
Where should I start writing my code? In one of folders created by
zopeproject or maybe I'm just supposed to create my own folders and
put them in pythonpath?
Heh, this is a *very* good question because I just realized that this
is nowhere documented clearly. I just assumed it would be obvious.
zopeproject actually creates an almost-empty package where you're
supposed to put the code for your web application. Let's say you
invoked zopeproject like this::
$ zopeproject MyZopeApp
...
Then inside the newly created 'MyZopeApp' directory,
$ cd MyZopeApp
you'll find a 'myzopeapp' package:
$ cd myzopeapp
$ ls
__init__.pyapplication.py configure.zcml
You can now add Python files to this package, register components in
configure.zcml, etc.
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?
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.
3. Does this work with workingenv? While trying to install
zopeproject with active workingenv I get:
#-
--
(env1)[EMAIL PROTECTED]:~/workingenvs/env1$ zopeproject newone
Enter user (Name of an initial administrator user): blablabla
Enter passwd (Password for the initial administrator user): blablabla
Enter eggs_dir (Location where zc.buildout will look for and place
packages) ['/home/pigletto/buildout-eggs']:
/home/pigletto/workingenvs/env1/buildout-eggs
Creating directory ./newone
Downloading zc.buildout...
Invoking zc.buildout...
Couldn't find index page for 'zope.app' (maybe misspelled?)
No local packages or download links found for zope.app
error: Could not find suitable distribution for Requirement.parse
('zope.app') (--always-copy skips system and development eggs)
This is interesting. I can reproduce this.
We got rid of the zope.app egg ages ago, which means that when run
within workingenv, buildout must be downloaded an ancient version of
some package that still depends on it. That again means buildout is
ignoring the find-links settings in buildout.cfg.
I've seen this behaviour once at the EuroPython sprint. I don't think
the person in question was using workingenv, but the symptoms were
the same. I thought it was an temporary anomaly ;), but it looks more
like a bug in zc.buildout. Or workingenv is doing something funny to
change easy_install's behaviour.
THanks for your input!
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
Philipp von Weitershausen wrote at 2007-7-18 01:13 +0200: ... Imagine you're writing a GUI application. Without question you'd use some sort of GUI toolkit (e.g. wxPython). Would you expect you would have to hook into the the wxPython application as a plug-in? Isn't it more natural that you simply write your application and just use the wxPython *library* wherever necessary? Is this not the difference between a framework and a library? An application uses a framework by hooking its components into the framework. A library is used directly -- only miminal hooking and callbacks are used. I view GUI frameworks typically as plugging my application parts into the GUI (which triggers my application code) -- especially, if the UI is build by an UI-builder... ... Zope 3 has now been successfully split up into separate pieces: individual libraries. I'd therefore like to propose an alternate approach to developing web applications with Zope: the library one, rather than the pluggable app one. I prefer the standard approach: I see a framework -- Zope and a large number of application components that plug themself into the common framework. The application, in fact a complete collection of mini-applications is configured via objects in the ZODB and can be extended TTW. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
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. 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? ;) ). This is interesting. I can reproduce this. Good to know that I'm not alone with this :) 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). -- Maciej Wisniowski ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
On 18 Jul 2007, at 21:13 , Dieter Maurer wrote: Philipp von Weitershausen wrote at 2007-7-18 01:13 +0200: ... Imagine you're writing a GUI application. Without question you'd use some sort of GUI toolkit (e.g. wxPython). Would you expect you would have to hook into the the wxPython application as a plug-in? Isn't it more natural that you simply write your application and just use the wxPython *library* wherever necessary? Is this not the difference between a framework and a library? An application uses a framework by hooking its components into the framework. A library is used directly -- only miminal hooking and callbacks are used. I view GUI frameworks typically as plugging my application parts into the GUI (which triggers my application code) -- especially, if the UI is build by an UI-builder... Good point. In a way, we're actually doing this. For example, our WSGI application gets called by PasteDeploy whenever the WSGI server receives a request. That's how we hook into the Paste framework. Then, we don't really do our own URL dispatching. The Zope publisher does its stuff and simply ends up calling our view code. That's how we hook into the Zope publisher framework. But then there are a bunch of things where *we* actually make the calls: assembling forms, calling a templating engine, etc. So, we're really doing both, using some frameworks and using some libraries. Maybe it's just a matter of where to draw the line. If some people (such as you) prefer to draw the line much closer to Zope-the- application, that's fine. I simply prefer to draw them closer to the loosely coupled libraries and frameworks. There's a reason for that. Zope-the-application is a big hindrance for using standard Python technologies such as eggs, WSGI, etc. It's not that eggs are going to solve world hunger (pun intended) and WSGI/ Paste isn't the end of the line when it comes to deployment, but betting on those and actually working towards sharing even more technology I think is the best thing we can do to grow Zope. I gave a lightning talk about this subject at EuroPython. I got several positive responses from Zope and non-Zoep folks, but the best was probably by Jacob Hallen who, if he ever has used Zope, probably wasn't a very enthusiastic Zope user. He said something along the lines of this: It's good to hear that Zope is starting to be usable in bits and pieces, without having to buy into the whole Zope world. Now, I bet there are lots of Python developers out there who like Jacob have turned their back on Zope over the years exactly because of this buy-in. Zope 3 has now been successfully split up into separate pieces: individual libraries. I'd therefore like to propose an alternate approach to developing web applications with Zope: the library one, rather than the pluggable app one. I prefer the standard approach: I see a framework -- Zope and a large number of application components that plug themself into the common framework. The application, in fact a complete collection of mini-applications is configured via objects in the ZODB and can be extended TTW. Right. This is what Martijn Faassen aptly calls the Zope 2000 development model. And it's probably about the farthest away from working together with other Python web frameworks and toning down Zope for an easier entry. I'm not going to try to convince anyone to give it up, but I probably won't spend much energy in either promoting, maintaining and documenting it. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
On 7/18/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote: I'm not going to try to convince anyone to give it up, but I probably won't spend much energy in either promoting, maintaining and documenting it. Yay, Philipp! -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
On Wed, 2007-07-18 at 18:50 +0200, Philipp von Weitershausen wrote: * 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? +1 * 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? I don't think this is unnecessary boilerplate for many projects, but it's not universal. What is the appropriate way to 'specialize' the zopeproject recipe for different 'default' purposes, one of which would be 'hello world'? 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. If the most common configuration changes can be gathered into a 'deployment' recipe, that would also be useful, I think. - Michael R. Bernstein signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] RFC: zopeproject
For the past weeks I've been toying around with egg-based installs of Zope and flexible WSGI-based deployment using PasteDeploy [1]. Both essentially challenge the concept of instances as we know them. What is an instance? * Start/stop scripts for a pluggable application called Zope * A collection of plug-ins for Zope-the-application (in Zope 2 these were called Products, in Zope 3 we say packages) that make up the web application. * Configuration of Zope-the-application (site.zcml) * Server configuration (zope.conf) So, an instance actually defines the web application by keeping plug-ins in lib/python or Products and by saying how they work together (site.zcml and package-includes). And then instances also define how they're deployed (again site.zcml, and zope.conf). Pluggable app vs. libraries --- While the idea of Zope as pluggable-application may have its value to some people, a library approach is much more natural to most Python developers. Imagine you're writing a GUI application. Without question you'd use some sort of GUI toolkit (e.g. wxPython). Would you expect you would have to hook into the the wxPython application as a plug-in? Isn't it more natural that you simply write your application and just use the wxPython *library* wherever necessary? Indeed it seems so, and that's probably why it really is that way. Zope 3 has now been successfully split up into separate pieces: individual libraries. I'd therefore like to propose an alternate approach to developing web applications with Zope: the library one, rather than the pluggable app one. The good news is that Zope is already there (thanks to the split-up). We just need to slightly change the way we develop applications with it. Writing an application using the Zope libraries --- How would you actually write an application that *uses* Zope instead of plugging into it? Simple. You do what any other Python developer does: start a package. Then proceed as follows: 1. Since you're using Zope you'll put all the kinds of Zope-based components in that package that you know: ZODB-persistent classes, views, Page Templates, etc. The more Zope components you use, the more dependencies your application will grow, which can all be tracked using the a standard setup.py script that we know from distutils/setuptools. 2. You configure the application's components. Surely you want the Zope publisher, the Zope security machinery, etc. So before configuring the applications own components, you want to load those components from Zope that you're reusing. That means your package's configure.zcml file will start off by including lots of Zope bits and pieces. Then it might configure all the components that are specific to your application. 3. You make the application startable. A GUI application would simply have a main() routine. A modern web application has a WSGI application factory. So, you'd write a WSGI application factory that does a few but necessary steps (usually that only involves parsing zope.conf and site.zcml) and then hands over the work to Zope's own WSGIPublisherApplication. (If that does sound like a lot of typing to you, don't worry. We'll solve that problem later.) The application is a single package! So what have we got now? A Python package that defines a WSGI-capable web application. And it's self-consistent! The whole web application is actually defined in that one package plus setup.py (which is needed for dependencies). If you compare that to the old instance-based approach, this is a *major* leap forward. With traditional instances, your application was made up of whichever plugins you had in lib/python or Products and whether or not they were enabled in site.zcml or package-includes. So developing on an application such as Plone led to interesting solutions like having the Products directory be a subversion checkout with lots of externals. I've seen similar solutions in the Zope 3 world, too. With eggs and and a library approach to Zope, this is a thing of the past: you simply install that one package and it contains a runnable, configured application. And because it lists Zope's libraries as dependencies, they will be installed automatically as well. So you no longer install Zope and then add the application code. You install the application, and Zope happens to be pulled in as a consequence. And if your application package specifies a specific version of Zope, people won't have problems by accidentally having installed the wrong version of Zope. Deploying the application - Thanks to eggs, the application is easily installed, including its dependencies. Thanks to WSGI and PasteDeploy, the application is also easily deployed: 1. Write a configuration file (e.g. deploy.ini) that connects the
