A coworker of mine wrote his own web server framework from scratch for an internal application. We're looking to migrate this application to Zope (thank God!). The only question we need to deal with is: The reason he wrote his own webserver rather than use CGIs is that there was some processing that needed to happen to initialize a system state -- basically, create an object that knows about the configuration of some things. In his model, this object is created at the beginning and is simply shared among the various Python objects/modules that are invoked when responding to user requests. How can I create such a persistent object that, say, a python script object or a page template could access? (Sure, handholding on this would be nice, but what I'm actually expecting is answers along the lines of "look into <foo>") -roy
Roy S. Rapoport wrote:
A coworker of mine wrote his own web server framework from scratch for an internal application. We're looking to migrate this application to Zope (thank God!). The only question we need to deal with is:
The reason he wrote his own webserver rather than use CGIs is that there was some processing that needed to happen to initialize a system state -- basically, create an object that knows about the configuration of some things. In his model, this object is created at the beginning and is simply shared among the various Python objects/modules that are invoked when responding to user requests.
How can I create such a persistent object that, say, a python script object or a page template could access?
Just write a Python product (there's a bit of boilerplate code, but that's pretty easy) that inherit from persitence.Persistant and can handle all that stuff, and instantiate one at the root of the application. ZODB will take care of the persistence, and acquisition magic will make this object accessible from all the application.
(Sure, handholding on this would be nice, but what I'm actually expecting is answers along the lines of "look into <foo>")
Look into Product, ZODB, and acquisition !-) -- Bruno Desthuilliers Développeur bruno@modulix.org
On Fri, Apr 08, 2005 at 11:30:23AM +0200, bruno modulix wrote:
Look into Product, ZODB, and acquisition !-)
Excellent. It looks like persistence may not be an issue here, actually, since I think the persistence I want -- hang around for the life of the Zope server -- is built in anyway, right? So what's a decent source these days for 'how to write a product' documentation? The Zope Developers Guide is in 2.4. -roy
On Apr 8, 2005 6:44 PM, Roy S. Rapoport <zope@ols.inorganic.org> wrote:
Excellent. It looks like persistence may not be an issue here, actually, since I think the persistence I want -- hang around for the life of the Zope server -- is built in anyway, right?
Yup, you would simply use the temp db for that. But "for the life of the server" is rather unusual... What are the objects you are doing, more specifically?
So what's a decent source these days for 'how to write a product' documentation? The Zope Developers Guide is in 2.4.
It hasn't changed that much. Stay clear of ZClasses and DTML. (Although, if you aren't planning to use any third-party products, you might actually want to look into using Zope3 instead, which is way cooler, but a tad more complicated to get started with). -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
On Fri, Apr 08, 2005 at 06:48:49PM +0200, Lennart Regebro wrote:
But "for the life of the server" is rather unusual... What are the objects you are doing, more specifically?
We're porting a web application to manage a collection of DNS and DHCP servers. At startup time, we talk to each of these DNS and DHCP servers to ask them what zones they know about (in the case of the DNS servers) and what pools of addresses they use (in the case of the DHCP servers). This information changes rarely, and costs some time to acquire. Actually having said this just now, I'd say a better solution for us would be to actually initialize an object when the user logs in -- we can tolerate that delay, and that gives us a relatively fresh snapshot of the current situation. Don't know how that changes things. It feels like it should make it easier.
(Although, if you aren't planning to use any third-party products, you might actually want to look into using Zope3 instead, which is way cooler, but a tad more complicated to get started with).
Hmm. I'd be willing to use Z3, I think -- I haven't done Zope development for about 6-9 months, but all my previous experience has been on 2.x. The other people involved in this are all brand new to Zope. Why should I use Z3? Does it have better documentation? :) -roy
On Apr 8, 2005 6:55 PM, Roy S. Rapoport <zope@ols.inorganic.org> wrote:
Actually having said this just now, I'd say a better solution for us would be to actually initialize an object when the user logs in -- we can tolerate that delay, and that gives us a relatively fresh snapshot of the current situation. Don't know how that changes things. It feels like it should make it easier.
Yes, and no. In that case I would just store the information as usual in the ZODB, that is, the data is persistent across server restarts, but call a method that updates it when you log in (or simply have a button to do it). But the difference is rather small, since yo just call the methods at different times, and store the information in different places.
Hmm. I'd be willing to use Z3, I think -- I haven't done Zope development for about 6-9 months, but all my previous experience has been on 2.x. The other people involved in this are all brand new to Zope. Why should I use Z3? Does it have better documentation? :)
Actually, it does, :) But mainly, it solves a lot of things that were problematic with Zope. All development is (currently, this will change) done on the file system, no more tricky Python Scripts for example. It also allows you to do more things in pure Python, and then "wrap" it in Zope configuration stuff. That makes test driven development easier, and also reusing pure python stuff gets easier. Read a bit about it, and see what you think: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FrontPage/Z... Zope2 is still good. Zope 3 is just better, in many ways, although it still lacks in third-party product support. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
On Fri, Apr 08, 2005 at 07:13:11PM +0200, Lennart Regebro wrote:
In that case I would just store the information as usual in the ZODB, that is, the data is persistent across server restarts, but call a method that updates it when you log in (or simply have a button to do it).
That works.
Actually, it does, :) But mainly, it solves a lot of things that were problematic with Zope. All development is (currently, this will change) done on the file system, no more tricky Python Scripts for example.
Hmm. Wouldn't this allow for massively simpler integration with CVS, then?
It also allows you to do more things in pure Python, and then "wrap" it in Zope configuration stuff. That makes test driven development easier, and also reusing pure python stuff gets easier.
Nifty!
Read a bit about it, and see what you think: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FrontPage/Z...
Zope2 is still good. Zope 3 is just better, in many ways, although it still lacks in third-party product support.
I'm a bit concerned about my perception of Zope 3's flux. I was especially dismayed to see, in the Z3 book, --- Zope 3 will come with an advanced ZODB to Filesystem synchronization tool, similar to CVS. This will allow people to make local copies of their sites work on it and check in the changes and much more. This recipe will explain how to effectively use this tool. Note: This chapter will not be included in the first version of the book, since Zope X3 3.0.0 will not ship with it and it is not actively maintained at this point. --- The first paragraph was great. The second wasn't :) -roy
On Apr 8, 2005 7:26 PM, Roy S. Rapoport <zope@ols.inorganic.org> wrote:
Hmm. Wouldn't this allow for massively simpler integration with CVS, then?
It does yes. But developing on the file system only is possoble with Zope2 as well, of course, so theres not actual difference there. However, typically with Zope2 you end up using CMF as well, and although scripts and ZPTs are stored on the filesystem there, CMF treats them as if they are not, and hence you have security restrictions, which means you have to use restricted python, and then you have to trick yourself around that, and so on forever... ;-) Easier to just have plain Python all the way.
I'm a bit concerned about my perception of Zope 3's flux. I was especially dismayed to see, in the Z3 book, --- Zope 3 will come with an advanced ZODB to Filesystem synchronization tool, similar to CVS. This will allow people to make local copies of their sites work on it and check in the changes and much more. This recipe will explain how to effectively use this tool.
Note: This chapter will not be included in the first version of the book, since Zope X3 3.0.0 will not ship with it and it is not actively maintained at this point. ---
The first paragraph was great. The second wasn't :)
Well, that was all a part of the ideas they had for through-the-web development, and that was put on hold to implement other stuff. With file-system development only, you don't need it. :) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
On Apr 8, 2005 11:05 AM, Roy S. Rapoport <zope@ols.inorganic.org> wrote:
A coworker of mine wrote his own web server framework from scratch for an internal application. We're looking to migrate this application to Zope (thank God!). The only question we need to deal with is:
The reason he wrote his own webserver rather than use CGIs is that there was some processing that needed to happen to initialize a system state -- basically, create an object that knows about the configuration of some things. In his model, this object is created at the beginning and is simply shared among the various Python objects/modules that are invoked when responding to user requests.
How can I create such a persistent object that, say, a python script object or a page template could access?
Is this persistent even among server restarts, or persistent per request, or persistent per session? (the answer is different for all of them, and usually, in Zope, "persistent" means "persistent over server restarts"). -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
On Fri, Apr 08, 2005 at 12:00:45PM +0200, Lennart Regebro wrote:
Is this persistent even among server restarts, or persistent per request, or persistent per session? (the answer is different for all of them, and usually, in Zope, "persistent" means "persistent over server restarts").
Ah, sorry. In this case, it's persistent for the life of the server, so we expect to re-initialize it when Zope restarts. Oh, and it'd be nice to give it a .reinit() capability too, if the user wants to refresh :) -roy
participants (3)
-
bruno modulix -
Lennart Regebro -
Roy S. Rapoport