- Zope-Dev - Zope lists

ZPatterns, ObjectDomain, UML and all that.....
by Steve Spicklemire 04 Dec '00

04 Dec '00

I've been working out some issues with EMarket, and as a way to 'clear the cruft'.. I decided to bite the bullet and do some more careful object modeling. Other than scribbling on paper, and making up some diagrams that look a little like those from Coad's book on Patterns and Strategies, I've never used any object modeling tools before in my life. Soooo... I downloaded the eval version of ObjectDomain, and I can go for about 5 minutes on a Mac before it crashes, and usually 10 or 15 on Windows before it stops responding to mouse/keyboard input. Save early, save often.. ;->. Sure it's frustrating.... but it seems more workable that ArgoUML which I've had even less luck with.... (What are other folks using? Rose?) anyway after much more time that I would have thought possible I've come up with: http://www.zope.org/Members/sspickle/EMarket/objectModel.gif which is not finished, correct, or even totally consistent with the current implementation, but it's a starting point. Based on this picture.... I have some questions for other folks out there who are doing object modeling and using ZPatterns, or who might just be willing to comment on a first hack at a model for EMarket. ---------------------------------------------------------------------- 1) One of my areas of confusion relates to the notion of an 'association'/'aggregation'. It seems that you can have a 'simple association', which I guess just means that one object can talk to another as equal 'peers'? This is denoted with a simple line, with no bubbles at either end. There is also 'composite aggregation', with a filled in bubble at one end (the container/master) and nothing at the other (contained/slave?). Finally there is 'shared aggregation', where there are multiple 'masters/containers' for a single 'slave/contained' object. Each 'master' in this case has an 'empty' bubble. Object domain has three labels for each connection. 1) a name for the connection itself, 2) a name for the source/from end, and 3) a name for the sink/to end. In the current implementation of EMarket, since the connections are actually implemented as Specialists, the only real connections is that a master/container will have a (possibly) empty list of ids that can be used to fetch the actual slave/contained object from the corresponding Specialist(s). In the case of a 'two way connection' would the connection have the name of one specialist in one direction, and another in the other direction: e.g., Shopper <--baskets ---- shoppers---> Basket)? Does this make sense? Are there other/better ways to think about and/or implement this idea with ZPatterns? ---------------------------------------------------------------------- 2) I've stumbled on different ways to implement these things. I'm sure there are other (better?) ways as well. One way e.g., is to store a 'barID' to make a connection, and a runtime, using "bars.getItem(self.barID )" to get it.. or.. store the Bar object itself in your DataSkin and hope that everything will sort it self out when it is next accessed. So far I've always kept an ID, then used getItem at runtime, when I needed the 'real' thing.... I remember some discussion on the list about keeping an Address object in a related DataSkin, which sounds great.. but I have/had some concerns. My retrieval code often looks something like this: theBar = bars.getItem(self.theBarID) if theBar: foo = theBar.getFoo() else: # do something about the fact that there was no Bar..... If I explicitly store a Bar object as an Attribute of a DataSkin then what happens if the original Bar is removed from its Specialist's Rack? Does the Bar I store still refer to the original Rack as its DataManager? So.. does a Rack sometimes have 'clients' that are not really in the Rack at all? Or perhaps I misunderstood the discussion, and the Address wasn't really a DataSkin at all? Also.. assuming that all works, do I have to do anything special, or carefully to be sure that the persistence machinery doesn't incur lots of expensive attribute fetching if I don't explicitly refer to those attributes, but have the DataSkin as a directly set attribute of another DataSkin? Another approach is to make theBar a computer attribute, e.g., WITH bars.getItem(self.theBarID) COMPUTE theBar=RESULT or NOT_FOUND which is sort of a (nice?) compromise between the two approaches, but it still requires that I keep an Id around.... Does anyone have comments/feedback on the merits of these different approaches? I'd love to come up with a set of 'best practices' for some of these issues. I'm trying to use ZPatterns, train other folks on how to use them, and learn the nitty gritties all at the same time... Life never used to be so interesting. ;-> ---------------------------------------------------------------------- 3) (Last question I promise!.. for now) Is there any real difference between the plain lines, open bubbles, and closed bubbles other than the number of (master) objects with relations to the (slave?). If both objects refer back to eachother, should there be two bubbles? (That doesn't seem to be an option with ObjectDomain.) Is there a good source on the net that talks about this stuff? I've been reading some of the specs at omg.org... and I'm guessing there's something out there more friendly ... but I haven't found it yet... ---------------------------------------------------------------------- OK.. that's it. Any feedback would be appreciated. When I get it all figured out I'll throw it all into the DumbZPatterns example with your feedback. thanks! -steve

2 1

Hmmmm.... what do *you* do when Zope is 'stuck'.
by Steve Spicklemire 03 Dec '00

03 Dec '00

Hi Folks, Ok.. this is the wierdest thing I've run into yet. Any ideas how to diagnose this would be most appreciated. It's a little bit like quantum mechanics. When you try to measure it... it changes. ;-) I have a Data.fs that has somehow gotten into a state where Zope just hangs there. I can attach to the python process with the debugger when it's running and dump the stack trace. It looks like this: #0 0x281af6c0 in _thread_sys_poll () from /usr/lib/libc_r.so.4 #1 0x281a806f in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.4 #2 0x281a775a in _thread_kern_sched () from /usr/lib/libc_r.so.4 #3 0x281a7b7e in _thread_kern_sched_state () from /usr/lib/libc_r.so.4 #4 0x281944c1 in wait4 () from /usr/lib/libc_r.so.4 #5 0x281865c7 in __waitpid () from /usr/lib/libc_r.so.4 #6 0x2816bba2 in waitpid () from /usr/lib/libc_r.so.4 #7 0x80890cd in pcre_exec () #8 0x8055069 in PyEval_CallObjectWithKeywords () #9 0x8054f73 in PyEval_CallObjectWithKeywords () #10 0x8054028 in PyEval_EvalCode () #11 0x8053f10 in PyEval_EvalCode () #12 0x805210d in PyEval_EvalCode () #13 0x80629a3 in PyRun_File () #14 0x806295c in PyRun_File () #15 0x806293c in PyRun_File () #16 0x8062046 in PyRun_SimpleFile () #17 0x8061cba in PyRun_AnyFile () #18 0x8050935 in Py_Main () #19 0x8050420 in main () #20 0x80503a5 in _start () The problem is somehow related to timing and threads. If I start Zope with only one thread.... no hang. If I start Zope with 'PROFILE_PUBLISHER' defined... no hang. I've added some debugger hooks at various places (e.g., ZPublisher, ZServer, etc... ) in an attempt to 'step' through the problem, but when I do.. it works! Ahhhh!!! I'm about to add some 'print' statements around but I'm fearing that if I add some print statements it will disturb the timing enough to destroy the electron interference patterns... er... I mean mask the problem. Has anyone got any ideas on how to track something like this down? The only other clue I have is that, at first, when I saw the problem, whenever I attached to the process it would be in the 'PoPymodule', so I naturally suspected PoPy. However, I've *removed* the ZPoPyDA Product from the Products folder (on the filesystem) , so that presumably PoPymodule.so will/should not be loaded or accessed. Anyway.... popymodule is no longer showing up in the stack trace, but still Zope is hanging.... All this started showing up by the way not long after we started experimenting with ZPoPyDA. But.. now that ZPoPyDA is gone... is there any way my Data.fs could be affected in a way that could cause this behavior? thanks for any insight.... -steve

2 3

how to access propertiesheets of a base ZClass
by Joachim Schmitz 03 Dec '00

03 Dec '00

in a derived ZClass I created a ZClass Field with a propersheet Basic with some Properties like: name,title,type,order and so on. I defined also a new view for this Basic Propertysheet FieldBasic. Now I defined an IntField ZClass with the Field as baseclass, and wanted to access and set for example the type-property. But in my new ZClass I don't have a FieldBasic management tab. If I create a new instance of Field I get the FieldBasic tab. any enlightment to this is welcome. Mit freundlichen Grüßen Joachim Schmitz AixtraWare, Ing. Büro für Internetanwendungen Hüsgenstr. 33a, D-52457 Aldenhoven Telefon: +49-2464-8851, FAX: +49-2464-905163

3 2

changing/storing Properties with ZPatterns
by Joachim Schmitz 01 Dec '00

01 Dec '00

Hi, I setup a Specialist with a ZCLass "AZ" for persistent storage. In AZ I setup a Dataskin propertysheet "Basic" with properties Name, Street etc. Now I made dtml-method form which iterates with: <dtml-call "REQUEST.set('ni',getItem(sid+id))"> <dtml-in "ni.propertysheets.Basic.propertyMap()"> over the Basic propertysheet,builds the form, and stores the values within another dtml-method edit with: <dtml-call "ni.propertysheets.Basic.manage_changeProperties(REQUEST)"> this works fine. Now I wanted to have attributes which I don't want to display in the form, for example complete attribute. I therefore created another dataskin propersheet Internal in AZ with a property complete and tried to set it with: <dtml-call "ni.propertysheets.Internal.manage_changeProperties(REQUEST,complete='1')"> But I don't manage to store retrieve this attribute. All attributes in the Basic propertysheet I can store and retrieve. what is the magic behind this ? Mit freundlichen Grüßen Joachim Schmitz AixtraWare, Ing. Büro für Internetanwendungen Hüsgenstr. 33a, D-52457 Aldenhoven Telefon: +49-2464-8851, FAX: +49-2464-905163

2 2

More ZPatterns confusion
by kent＠tiamat.goathill.org 01 Dec '00

01 Dec '00

I have a persistent object class I'm trying to model in ZPatterns. --------------------------- MasterRack Class: A physical Master Rack is composed of 96 tubes of DNA, one tube per DNA sample, organized by families.

1 0

ZIdle, anyone?
by cg＠cdegroot.com 01 Dec '00

01 Dec '00

I've cooked up a quick IDLE extension that connects to ZEO and shows a DB Browser, like the class/path browser. It's already great fun (quick lookups through a Tkinter tree control beat the heck out of HTML), and although my Tk is rusty, I think that Tk's HTML widget supports just enough HTML to display management screens (that's step 2). Now, before I go off and reinvent wheels, is this a new idea or not? Code says more than 1000 words: 1. Startup script (change zope and idle locations) -------------- #/bin/sh PYTHONHOME=/opt/zope/current export PYTHONHOME PYTHONPATH=/opt/python/idle-0.5 PYTHONPATH=$PYTHONPATH:$PYTHONHOME PYTHONPATH=$PYTHONPATH:$PYTHONHOME/lib/python PYTHONPATH=$PYTHONPATH:$PYTHONHOME/Extensions PYTHONPATH=$PYTHONPATH:$PYTHONHOME/ZServer/medusa PYTHONPATH=$PYTHONPATH:$PYTHONHOME/ZServer export PYTHONPATH /usr/bin/python zidle.py -------------- 2. Zidle script -------------- if __name__ == "__main__": from ZEO import ClientStorage from ZODB import DB from Zope import ClassFactory global App global Conn global Db storage = ClientStorage.ClientStorage(('', 8001)) Db = DB(storage) Db.setClassFactory(ClassFactory.ClassFactory) Conn = Db.open() App = Conn.root()['Application'] import PyShell, sys sys.argv = ['', '-t', 'ZIdle', '-c', 'from zidle import App, Conn'] PyShell.main() -------------- 3. Browser ------------- from TreeWidget import TreeNode, TreeItem, ScrolledCanvas from WindowList import ListedToplevel import PyShell class DbBrowser: def __init__(self, dbnode): self.dbnode = dbnode self.init() def close(self, event=None): self.top.destroy() def init(self): self.top = ListedToplevel(PyShell.flist.root) self.top.protocol("WM_DELETE_WINDOW", self.close) self.top.bind("<Escape>", self.close) self.settitle() self.top.focus_set() sc = ScrolledCanvas(self.top, bg="white", highlightthickness=0, takefocus=1) sc.frame.pack(expand=1, fill="both") item = self.rootnode() self.node = TreeNode(sc.canvas, None, item) self.node.update() self.node.expand() def settitle(self): self.top.wm_title("DB Browser") self.top.wm_iconname("DB Browser") def rootnode(self): return DbBrowserTreeItem(self.dbnode) class DbBrowserTreeItem(TreeItem): def __init__(self, dbnode): self.dbnode = dbnode def GetText(self): try: return self.dbnode.title_and_id() except: return `self.dbnode` def GetIconName(self): try: if self.dbnode.isPrincipiaFolderish: return "folder" else: return "python" except: return "python" def GetSubList(self): sublist = [] for i in self.dbnode.objectIds(): sublist.append(DbBrowserTreeItem(self.dbnode[i])) return sublist def IsExpandable(self): try: return self.dbnode.isPrincipiaFolderish \ and len(self.dbnode.objectMap()) > 0 except: return 0 def main(): from zidle import App DbBrowser(App) if __name__ == "__main__": main() ---- 4. README Hit "dbbrowser.DbBrowser(App)" in the IDLE console and have fun. -- Cees de Groot http://www.cdegroot.com <cg(a)cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B

1 0

CustomizerFolder and the order of things in general
by Stefan H. Holek 01 Dec '00

01 Dec '00

I am in the process of developing a product that patches the Folder class at runtime - the Hotfix way. I append an additional tab to the Folder class' manage_opions from the __init__.py of my product. While this works fine for standard Folders and the Folder derived products I've tested, ZPattern's Folder w/Customizer Support is giving me headaches. I tracked it down to this code in the CustomizerFolder class: # We want to look like a folder, but with extra tabs after 'Contents' manage_options_left = Folder.manage_options[:1] manage_options_right = Folder.manage_options[1:] So they manage to whack off the original manage_options before I can patch them, sigh. ;) I am not sure about the order of events here. Is there such a thing as product initialization order? Will code like the above always use the "hardwired" attributes of a class definition, and never any hotfixed changes? How about coding style then. What is considered worse, hotfixing or refusing to be hotfixed? ;) Thanks, Stefan -- Things work better when plugged in

1 0

Allowed Product Changes
by Robin Becker 01 Dec '00

01 Dec '00

I'm building some Products in python and find it very difficult as I never know when a source change is going to render the data for existing instances invalid. Sometimes when this happens it takes down the containing folder as well. Are there any obvious do's and don'ts and how-tos when modifying an existing product? What makes instances break for example? -- Robin Becker

1 0

Re: [Zope-dev] Return variables from a DTML Method
by Tres Seaver 01 Dec '00

01 Dec '00

bentzion(a)bellatlantic.net asked: > > I want to change some ZClass properties by getting return results > from a DTML Method. Something like this: <dtml-call > "myzclass.propertysheets.get('Basic').manage_changeProperties(dtmlM > eth(this(),_))">. How do I get the dtmlMeth to return a Mapping? > (or should I be doing this a different way?) You *could* return a dictionary from a DTML method: DTML Method 'return_dict':: <dtml-return expr={ 'foo' : 0, 'bar' : 1 } DTML Method 'show_dict':: <dtml-var standard_html_header> <h2><dtml-var title_or_id> <dtml-var document_title></h2> <dtml-let dict=return_dict> <p> Foo: <dtml-var "dict['foo']"> <p> Bar: <dtml-var "dict['bar']"> </dtml-let> <dtml-var standard_html_footer> ....but I can't imaging wanting to. Try to rearrange your stuff so that the code generating the mapping can call 'manage_changeProperties()' its own self, or else move it to PythonScripts/PythonMethods/ExternalMethods/a Product; you'll be glad you did. Tres. -- =============================================================== Tres Seaver tseaver(a)digicool.com Digital Creations "Zope Dealers" http://www.zope.org

1 0

Re: [Zope-dev] RFC: Python/Zope Interfaces
by Dieter Maurer 30 Nov '00

30 Nov '00

Michel Pelletier writes: > Also, defining the interface seperately keep the two things apart, > impementation and interface, and doesn't allow you to sneak in a new > method unless you also sneak it into the interface, thus making a > stronger "contract" with the user. I am a bit astonished by this statement: I know the "design by contract" concept from Bertrand Meyer, the Eiffel developper. In Eiffel, essential parts of the contract, among others method prototype, pre- and post-conditions as well as invariants are build directly into the language. A documentation tool extracts these parts from the source to generate the interface, for people that are only interested in how to use the class/method. Programms can be executed in a way, that the various (executable) contract parts can be checked at runtime. *THIS* provides for quite a strong contract. I cannot see, why the separation of interface and implementation should make the contract stronger. I do see, however, that it makes it more likely to be broken by the implementation. It is a very good thing to have the specification very near to the implementation -- as a permanent guide to the implementor. It is even better, when big parts of the specification becomes part of the executable code (as is the case for Eiffel's pre- and post-conditions). If you want to prevent your implementors to change the interface specification, generate the interface for the implementation and compare against your master copy. In my view, it is better to have a somewhat "weaker" contract that is met by the partners than a "stronger" contract that is violated. Or, to say it differently, it is more essential the a system's documentation describes faithfully what is rather than what should be (but is not). Dieter

5 14