Python object lifecycle? (was Re: [Zope] Where to put business logic? logic?
Not to start a "what IS client server?" discussion (I thought we got past that in the last millenium), but it looks to me like Zope IS the middle layer. In terms of layers, the browser "front end" handles presentation (client), the "back-end" (data server, host) is an RDB, or CD tower (of image files), or whatever, then the integration layer "middle" is Zope. It really doesn't change whether you call it "middleware", "application server", "content manager", etc. In other words, Zope is where you get to build in the business logic, as objects, and find relief from the narrow bounds of SQL. Of course, the Zope layer can be fairly complex and is subject to being defined as having multiple layers within itself, but that's another thread.
Jerry Spicklemire wrote:
Not to start a "what IS client server?" discussion (I thought we got past that in the last millenium),
Yes.
but it looks to me like Zope IS the middle layer.
Hmmm... I don't know about that. I guess it can be...
In terms of layers, the browser "front end" handles presentation (client), the "back-end" (data server, host) is an RDB, or CD tower (of image files), or whatever, then the integration layer "middle" is Zope.
I disagree. (OK, I admit that this is somewhat silly, because there's really many layers here, and what we call them isn't all that important.) A browser is a weird thing. It's not really a full client on it's own, since DHTML / Javascript really sort of died. Now, a Java applet in a browser -is- a front-end to me. But, using just plain html in the browser means that the front end must be split between the client and server. So, what you get is this: { "Pure-HTML" in browser scenario } Name: Front End Responsibilities: Reacting to user input, rendering information Location: Split between a web browser and an HTML/HTTP server. (CGI, Zope, Servlet, etc.) Name: Middle Tier Responsibilities: Business Logic. Ie: user authentication, rule enforcement, brokering, trading, bus-like behavior. Location: On the same or different computer as the HTML/HTTP server. Name: Backend / Datastore ..... So, the issue here seems to be that Zope absolutely does the Front-End stuff. (Plain old content management, style-like HTML rendering, etc.) But, the real questions are does / should / can Zope do the middle tier stuff? Usually it's nice middle tier is a long running process. It can be programmed in an OO style, and in a *stateful* manner. It looks like Zope's answer here is to write Python classes that get used as external methods. What's not clear to me is how these Python objects live and die, and when. - Robbb
It really doesn't change whether you call it "middleware", "application server", "content manager", etc.
In other words, Zope is where you get to build in the business logic, as objects, and find relief from the narrow bounds of SQL. Of course, the Zope layer can be fairly complex and is subject to being defined as having multiple layers within itself, but that's another thread.
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
On Fri, 18 Feb 2000, Robb Shecter wrote:
It looks like Zope's answer here is to write Python classes that get used as external methods. What's not clear to me is how these Python objects live and die, and when.
Just thought I'd drop a quick note to say that, IMHO, external methods are NOT the way to go, here. External are targeted towards a limited problem domain, and have several disadvantages. Chris Petrilli, in his "Zope for Developers" talk at IPC8, discussed this issue briefly. The advantages of external methods, in his slides are: - Familiar Python code-base. - Access to all Pythonisms and modules While the disadvantages are: - Can be very unsafe - Ideological disconnect - Stored externally and not versioned. External methods are great when you say, for instance, "I have everything I need for this site EXCEPT I could really use an md5 hash of the user's IP address when computing an identity cookie." You just make a "compute_md5_hash" external method, implement it using Python's md5 capabilities, and acquire it into any site you want to use it in. However, for something as complex as business rules, I would make a Python product. This way you can build a complete class hierarchy if you need to, calling into your Python instances from Zope and/or having Python call back into Zope. Any initialization can be done at Product load time in __init__.py. This all requires a little more Zope Zen than creating a few hundred external methods, but you will fine the outcome much more safe, understandable, and easy to maintain.
- Robbb
--Jeff PS. See Chris's slides at: http://www.zope.org/Members/petrilli/Presentations/IPC8/Developers.htm --- Jeff K. Hoffman 704.849.0731 x108 Chief Technology Officer mailto:jeff@goingv.com Going Virtual, L.L.C. http://www.goingv.com/
participants (3)
-
Jeff K. Hoffman -
Jerry Spicklemire -
Robb Shecter