Thanks for the response. The reason for wanting to use ZRoundup is to have an instance of Zope in use in the organisation (which is a python shop). I'm particularly interested in seeing how far it's possible in Zope to separate the various elements of web apps in general - zpts have done it largely for the content side, and I'd like to have the app in python, with a Zope "front end", which was the model being shown here. So if I'm developing a python app for the web, I can put all the functionality in, say, the App class, and have a ZApp class as front-end which inherits all the functionality from App by subclassing, and itself only handles the Zope interface elements. The only fly-in-the-ointment I've found to date is that writing a Zope app with an RDBMS from scratch I'd probably want to use ZSQLMethods (as the framework handles them "naturally") and so the python App class has to know about it's frontend and the elegance goes away. Or maybe I'm approaching this Zope-with-SQL problem from the wrong end. What's your experience? Finally, the answer to your question as to why is: "learning, while broadening the general python and python-related base and expertise". Tim --- Chris Withers <lists@simplistix.co.uk> wrote: > Hi Tim,
Tim Couper wrote:
Has anyone successfully deployed the issue tracking system Product ZRoundup?
The guys at Upfront Systems (http://www.upfrontsystems.co.za/) said that it was pretty half baked when they tried it and recommended just using Roundup on it's own behind Apache.
Why the particular interested in ZRoundup over Roundup?
___________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html
Tim Couper wrote:
possible in Zope to separate the various elements of web apps in general
Depends on what you see as the various elements of web apps in general ;-)
the content side, and I'd like to have the app in python, with a Zope "front end",
Ah, you'll be wanting Zope 3 then ;-) (if such a beast ever stops morphing its implementation every 2 days...)
being shown here. So if I'm developing a python app for the web, I can put all the functionality in, say, the App class, and have a ZApp class as front-end which inherits all the functionality from App by subclassing,
No, no, subclassing is bad. Most people prefer to approach this with component-type solutions, which I hope Zope 3 is still using. The idea is you have your python class that does what it wants, say a python email.message, and then write adapters as necessary to make it do what you want. I think ZODB persistence is the only thing which doesn't work this way in ZOpe 3. Anyway, aside from that you can use any python module/class you want without hav ing to subclass it and worry about who inherited what from whom... Sadly, in Zope 2, you need to subclass and mix-in the stuff you need, OFS.Folder or OFS.SimpleItem usually cover the bulk of it, but they bring loads of baggage with them.
The only fly-in-the-ointment I've found to date is that writing a Zope app with an RDBMS from scratch I'd probably want to use ZSQLMethods (as the framework handles them "naturally") and so the python App class has to know about it's frontend and the elegance goes away.
Hurm, maybe it just needs to be agnostic about what it's backend is here? For example, your class may have a "getData" method, this may raise NotImplemented or may load data from a file in the pure Python version, in the Zope subclass it may look like: def getData(self): return self.my_zsql_method_in_my_containing_folder() cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (2)
-
Chris Withers -
Tim Couper