- Zope - Zope lists

Help with DTML
by Tom Wright 11 Mar '00

11 Mar '00

Hi DTML Gurus, I am a newbie with DTML and i am trying to do the following with this script 1) using the subdirectory RegisteredUsers, check if a ZClass object of type Player exists in the RegisteredUsers directory with an id that matches that in the Request ( a form from the client ). This currently doesnt work for some reason and i get the else case even if the object does exist. 2) In the else case i am then trying to create a new object of type Player a ZClass object defined in the GameSite product ). I am creating the object correctly in the correct place but the next bit of setting the properties of the player object does not work, and the object properties are blank. HELP !! I have checked all the documentation for zclasses, dtml faq etc. Can any one help? Is there an easier/better way of achieving what i am trying to do, or am i barking up the wrong tree ? <dtml-with RegisteredUsers> <dtml-if REQUEST['new_user_name']> User currently exists <dtml-else> New user <dtml-with "manage_addProduct['GameSite']"> <dtml-with "Player.createInObjectManager(REQUEST['new_user_name'], REQUEST)"> <dtml-call nage_changeProperties( user_name = REQUEST['new_user_name'], password = REQUEST['new_password'], player_name = REQUEST['new_player_name'], planet_name = REQUEST['new_planet_name'], email = REQUEST['new_email'], )" > </dtml-with> </dtml-with> </dtml-if> </dtml-with> Regards Tom Wright thomas.wright1(a)btinternet.com

2 1

RE: [Zope] Zope needs this (and Dynamo has it)
by Alexander Staubo 11 Mar '00

11 Mar '00

> From: 'Martijn Faassen' [mailto:faassen@vet.uu.nl] > Sent: Thursday, March 09, 2000 1:15 PM > To: Zope Mailing List (E-mail) > Subject: Re: [Zope] Zope needs this (and Dynamo has it) > Pardon me for sending off another email in mid-stride. Damn cat :-) Let me finish the last sentence first: I also have a database-centric Zope app that causing me headache. The ZODB is *way* too immature to replace a database right now -- fine for the kind of stuff that runs on zope.org, not for us. We're actually looking at alternative app servers and solutions (such as hardwired C++ CGI code) right now. It's a shame, and I'm fighting it, but we might end up with something like Dynamo. [snip] > > Python has plenty of problems, but they're tiny by > comparison and imho > > they're mostly artifacts of Python's currently somewhat > anemic syntax > > (eg., only two kinds of loops, no "switch", no protected members, no > > constants, no syntax for declaring mutability). > > I suggest you go discuss these things on comp.lang.python. :) I don't necessarily say they're _my_ problems, but some people think they are, and that counts. I don't miss "switch" myself, although I do miss a kind of enumerated type. > I don't miss switch. Functions are first class objects, and > dictionaries > can be used instead of switch when necessary. Also, good > object oriented > design tends to kill switch statements anyway. I remember sitting down with Python for the first time create a simple CGI type thing, and found that I could just do def DoSomething(): ... def DoSomethingElse(): ... DoSomething(eval('Do' + Args['cmd'])) and then call up the CGI using a query string such as /cgi-bin/foo.py?cmd=Something. Wonderful, and better than any kind of RTTI. > I think the two loops are fine, though it would be nice to have the > current constructs to know about iterators. I believe Guido is > taking that into consideration. Also there's the list-comprehension > proposal which may help here. The list comprehension syntax is cute, but not, I think, so clever. Perhaps it'll prove to be a nice feature, even a successful one, but personally I doubt, even with the knowledge in the back of my head of how this stuff works, that I would instinctively grasp for a list-comprehension expression as naturally as I grab for, say, a "while" loop. My head is just not wired that way, and I think the syntax looks positively alien for Python -- it's not "pythonic". > I don't think you'll see protected members any time soon. I think Zope's source code is one huge, glowing argument in favour of having protected members. > I'm not sure what you mean with syntax for declaring > mutability, though > it sounds interesting. I don't particularly take to the idea of a having mutability/immulatibility property burned into the type itself. Tuples are immutable, dicts and lists are mutable. Why? Because Guido says so. Jon Udell, I think it was, has argued that tuples are currently a redundant element in the language. Why have two kinds of lists? It just confuses people. A syntax for declaring the mutability of types would be helpful in clearing out this mess. For example, you should be able to declare a dict to be immutable when passed to a certain function call -- ie., forcing a copy. Python has no "out" parameter, only "in" parameters that are mutable depending on the type of the object passed. The syntax I'm alluding to would effectively give you both "out" and "const" parameters. > [snip code generator extension idea] > > Something like that would definitely be neat. The hard part would be > in the translation process, of course. The other part is in the > interfacing with regular Python; do you allow your translated function > to refer to other Python objects? If you do, you're opening a can of > worms. If you don't, then it starts to look like the 'Swallow' subset > of Python I proposed once; a strict subset of Python with > added full type > annotations, which is translatable into C or native machine code. I haven't thought it through. I just think it was potential. Why shouldn't the translated function refer to other objects? The function would essentially just constitute native calls to the Py* APIs -- in effect, a translated function would summarize the runtime calls made by the interpreter during normal execution. Therefore, non-translated Python code could just as easily refer to translated code (within a "translated module", which would be a special object), because the translator module would construct the necessary proxy object to forward external calls to the inner code. Or something. ;-) > > It would be an interim solution for certain CPU-intensive > modules, in > > anticipation of such built-in functionality in CPython > itself. Possibly. > > If you're starting such a project I want to hear more about it! I'll let you know. ;-) -- Alexander Staubo http://alex.mop.no/ The difference between theory and practice is that, in theory, there is no difference between theory and practice.

2 1

RE: [Zope] Zope needs this (and Dynamo has it)
by Alexander Staubo 11 Mar '00

11 Mar '00

> From: 'Martijn Faassen' [mailto:faassen@vet.uu.nl] > Sent: Thursday, March 09, 2000 1:15 PM > To: Zope Mailing List (E-mail) > Subject: Re: [Zope] Zope needs this (and Dynamo has it) > > > Alexander Staubo wrote: > > > From: Martijn Faassen [mailto:faassen@vet.uu.nl] > [I list a number of projects about improving Python] > > > People are indeed working on Python, but not to the extent of more > > popular projects like Linux or even, I believe, Perl. > > I don't know enough about Perl to judge this, but to me, there's > plenty of activity out there. Of course there could always be more, > but lots is happening.. We have _three_ independent implementations of > Python, for instance (Python, JPython and Vyper, and then there are > projects like Python2C). True enough, though I'd have liked to see more, and I'd have liked to contribute more, too, which is to say, I'd like to contribute at *all* -- no time for that at the moment, however. Ironically, I'm too busy using it to improve it. I find it ironic that JPython is even *slower* than CPython. Curious -- is anybody using it for anything worthwhile? > > Compiler/language projects have, historically, not thrived in the > > collaborative world of open source software -- for very > specific reasons > > inherent in the concept itself of languages and compilers. > Still, I'm > > very impressed with the evolution of next-gen GCC (formerly EGCS). > > Sure, it's not easy to do. I would debate that compiler/languages have > not thrived in the open source world, though. There seem to be > quite a few successful open source languages around. I'm not disputing the success of these languages. Perl, Python, PHP, Pike -- they're all quite successful at what they aim to be (*). But people tend to use languages rather than contributing to their development. You can't just evolve a language indiscriminantly, which is why we have Guido and Larry, the benevolent dictators. You can't just go, "oh, and I added iterated loops today". Every damn little feature requires at least some kind of ratification process. Languages are much more susceptible to breaking. (*) Except possibly Pike. I'm ashamed to say it, but I find myself oddly attracted to this language, if mostly because of its speed and interesting resemblance to C. Pike is a good example of "how to make a powerful language/interpreter system that's also very fast". Pike has had a type system from the outset, which is a definite edge over Python. > [assessment of Vyper with which I agree] > > > Anyway, while I have not been monitoring the Python > type/interface SIG, > > it seems to be moving quite slowly. > > That's the nature of discussion lists, almost. There are some > prototype > implementations of type-checking systems for Python, though (I think > two or three independent ones, in fact). Where? The type system SIG has a funny intro: "Recently, the types SIG has come under attack for inactivity, and in response Paul Prescod has offered to guide the SIG towards accomplishing a single specific goal: to develop an optional static typing system for Python. The December 1999 archives of the SIG show the discussion that lead to this decision." Reading this stuff now. It's interesting. I hope they get it right. Maybe I'll chip in. What's interesting about Dylan is that, because it relies on static information such as type hints and class/method relationships to be efficient, the developers of Functional Developer (formely Harlequin Dylan) are facing a design problem related to how they compile programs. They've actually put all of the various libraries into shared DLLs. Unfortunately, this means they lose the benefits of the optimizations that can be made through the use of static compiler information. When you load up the [latest beta of the] Developer IDE and compile a program, it consumes a whopping 45MB of RAM. And it's damn slow. The absence of such optimizations is one reason for this hogging tendency. So they're planning on providing a "whole program delivery" option whereby all libraries would be statically linked. > [Python people say speed is generally not the problem] > > > It is _less_ of a problem, but most Pythoneers are indeed > > > interested in > > > speeding of the language. I haven't heard of zealots who > want to hold > > > back speedups, as long as it doesn't do away with the power. > > > > I'm not saying they're holding back, but rather they're > dismissing speed > > and scalability as being a problem. I firmly believe that speed is > > Python's number of problem today, and it's keeping Python from being > > used in more applications. > > Hm, but in my experience Python has been shown to be plenty > fast enough > for the majority of applications. You're probably right though, and I > agree completely that a faster Python would be very nice. I have several apps where I would rather use Python, but where speed is so significant that I would either end up writing a lot of the code in C++ for speed (which is painful due to the lack of integration between the two languages -- Python classes can't inherit from stuff in the C++ extension, for example). I also have a database-centric Zope app that causing me headache. The ZODB is *way* too immature to replace a database right now -- fine for the kind of stuff that runs on zope.org, not for us. ream > > > Python has plenty of problems, but they're tiny by > comparison and imho > > they're mostly artifacts of Python's currently somewhat > anemic syntax > > (eg., only two kinds of loops, no "switch", no protected members, no > > constants, no syntax for declaring mutability). > > I suggest you go discuss these things on comp.lang.python. :) > > I don't miss switch. Functions are first class objects, and > dictionaries > can be used instead of switch when necessary. Also, good > object oriented > design tends to kill switch statements anyway. > > I think the two loops are fine, though it would be nice to have the > current constructs to know about iterators. I believe Guido is > taking that into consideration. Also there's the list-comprehension > proposal which may help here. > > I don't think you'll see protected members any time soon. > > I'm not sure what you mean with syntax for declaring > mutability, though > it sounds interesting. > > > Imho Python's second big problem is what you might call, in > lack of a > > better term (I'm not wearing my compiler-writer hat right > now, sorry), > > contractual semantics -- anything from static typing (pass > a string to a > > function that takes an int and you get either a compilation > error or an > > exception) to interfaces (the ability to enforce semantic > compatibility) > > to design-by-contract constructs. > > The types-sig is reaching consensus about optional static typing and > Guido does want to include that into the language in the > future (beginnings > in 1.7, full implementation in Python 3000 aka Python 2). > Interfaces are > being considered too, and Jim Fulton in fact has an > interfaces proposal > out there (that may get used in Zope's code base). > > I think using a unit testing framework can substitute for design by > constract constructs myself. > > [snip] > > > It'll be pretty difficult to make a beast like Zope exploit > > > type-hints, though, I think. > > > > I disagree, but there's only one way to find out -- implement it (or > > simulate it very carefully). > > Okay. > > [snip code generator extension idea] > > Something like that would definitely be neat. The hard part would be > in the translation process, of course. The other part is in the > interfacing with regular Python; do you allow your translated function > to refer to other Python objects? If you do, you're opening a can of > worms. If you don't, then it starts to look like the 'Swallow' subset > of Python I proposed once; a strict subset of Python with > added full type > annotations, which is translatable into C or native machine code. > > > It would be an interim solution for certain CPU-intensive > modules, in > > anticipation of such built-in functionality in CPython > itself. Possibly. > > If you're starting such a project I want to hear more about it! > > [snip] > > > All true. Anyway, the only thing you're wrong about is that > > > Pythoneers aren't > > > interested in improving performance. They are, but I grant > > > you they're not > > > performance nuts like users of C or C++. :) > > > > Well, I guess they're too busy arguing about whether Python > should allow > > assignments as expressions so you could do "while line = > f.readline():". > > ;-) > > Not to mention indentation! Anyway, the people who keep bringing these > things up don't tend to be the Python nuts (mostly they're > the newbies). > > Regards, > > Martijn > > > _______________________________________________ > Zope maillist - Zope(a)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 ) >

2 1

A ZCatalog ID bug?
by R. David Murray 11 Mar '00

11 Mar '00

I've got a simple CatalogAware ZClass. (CatalogAware is the only class I added to its inheritance list.) Everything seems fine, but if I access an instance of the ZClass through the Catalog by doing, say, getobject(data_record_id_), and then inspect the 'id' property of the returned object, instead of getting the id of the object I get the id of the folder in which the Catalog lives. When I create class instances, the 'id' in the meta-data is correct. If tell the catalog to update itself (or tell an item listed in the catalog to update itself through the catalog management screen), then suddenly the metadata id is also the id of the folder enclosing the Catalog. Is this a bug, or am I doing something stupid? The object appears under its id in all of the management screens, including the 'indexed items' tab of the Catalog. --RDM

1 0

Re: [Zope-dev] Missunderstanding of DTML Methods and acquisition?
by Michel Pelletier 11 Mar '00

11 Mar '00

This thread is more appropriate for the main list. zope-dev is for development topics. "R. David Murray" wrote: > > I'm finding this to be one of the trickiest "simple bits" of dtml to > learn, even after having read the docs. The following should work > in your /user/regions/index_html (tested): > > <dtml-var IManager> > > As you may already know, the following will instead get you quoted > text of the IManage method: > > <dtml-var "IManager"> > > The following will also work (tested): > > <dtml-var "IManager(_.None,_)"> > > This passes a 'client' of None and the namespace (that img exists > in) to the method. (I presume that in the first working example above > Zope supplies the client and namespace to the method when it evaluates > it). Correct. > This call form is of course what you'll need if you want to > pass arguments to the method: > > <dtml-var "IManager(_.None,_,somearg='someval')"> > > What I'm most confused about right now is when it is necessary to pass > the client and namespace and when you can omit it. It is necessary when you want to call a DTML Method or Document from a Python expression and you want that DTML Method or Document to be able to look things up as an attribute of a 'client' or in your current namespace (or any namespace you provide). You can omit it when you are using a DTML Method or Document _by name_ in DTML. Note that: <dtml-var IManager> is the same as: <dtml-var name="IManager"> and: <dtml-var "IManager()"> is the same as: <dtml-var expr="IManager()"> So most people use the first and third shorthand forms to use an object by name and to execute a python expression respectivly. When the DTML Engine sees that you are using an object by name, it tries to do clever things, like detect if it is a DTML object and to call the method and pass the namespace 'magically'. When the DTML engine sees that you are using an expression, it assumes you know what you are doing and does no magic for you. Therefore, you must explicitly pass in the namespace. > I'm also very unclear > as to just what the 'client' is, especially since most of the examples > I've seen involve passing in None for the client. The 'client' is an object that you want to use as a namespace. For example, if DTML Method 'IManager' wants to find the name 'img' you can pass a client object, and the method will try and do a getattr(client, name) (in this case, name being 'img'). If you pass a namespace, then it will try and do a namespace[name]. If neither of these succeed, it will look for the name in the optional list of keyword arguments you can provide. If that fails, it raises a NameError. The reason why it is None in most cases is because you want your method to look things up using the Zope DTML Namespace (affectionately known as '_'). In some special case however, you may want to explicitly provide some other object. This is single handedly the #1 obfusication in Zope and the most frequently asked question. We, of course, did not obfusicate this on purpose. When DTML was first concieved it worked by name only, so the behind the scenes magic was acceptable and intuitive. Later, we added python expressions, and the ugliness of calling DTML Methods and Documents became aparent. -Michel

1 0

Re: [Zope] zope.org Members list
by Martijn Pieters 11 Mar '00

11 Mar '00

From: "David Kankiewicz" <kankie(a)thegrid.net> > > A next call to Members will return this cached information. Timeout of the > > cache currently is 60 minutes. So, the batched pages and the searches use > > this cached information. > > What about a ZCatalog being updated every hour??? I would think two or > more hours would do... > Have a cron job do it... This might be a better idea. I'd use an external file, however. Thtis would indeed solve quite a few points on the list I gave: > > 1/ The cache has expired or is empty: we have to fill it again. User will alway read from file, is fast (shared locking). A cache update would do a exclusive lock at the end of the data gathering period, write quickly, unlock again. > > 2/ The cache is per-thread. <...> > > 3/ The volatile attributes don't hang around as long as I expect them to. <...> No longer. > > 4/ The dictionary containing the cache may be coming from swapped memory. > > Currently, the Zope.org process grows quite large. This may have to do with > > the up to 42000 Folder objects loaded into memory at any time. The Members > > Folder holds references to 6000 Member Folders, and there can be up to 7 of > > them (7 threads). This is an area where a BTree based folder would _really_ > > help. > > should solve this too, unless people are surfing all those folders... This doesn't solve this. It's not the surfing of all those folders, it's the accessing of the Members Folder itself. It's that folder that holds the references of 6000+ sub Folders. <...> > > 6/ CPU is hogged. The rendering of the ZQR is very expensive. If it runs, > > the whole of Zope.org suffers. I am seriously considering disabeling it. > > People really onlly need the pre-rendered version. I was testing just now, > > had to wait way too long, and noticed someone was looking at both the normal > > ZQR (rendering from XML), and the print preview version. The Members roster > > came from cache. > > I know would come one of these days :) > I'll be working on it tonight and starting to update it more actively. > (more complete, different format, etc.) > First thing I can think of is to make it all static, atleast the big > ones. Please. Amos was going to spend some time looking into optimizing the code, but not offering a dynamic version would bemuch better. There really is no need for one. Thanks! Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ | The Open Source Web Application Server ---------------------------------------------

1 0

Form Submit question
by Kulpinski, Dejan 11 Mar '00

11 Mar '00

Hello all, Is it possible to submit the form by clicking on the link and not on the submit button? In other words I would like to submit my form without having the submit button present. Now, I now I can do this using JavaScript on client side, by doing something like: <a href="MyFunc();"> The Link </a> MyFunc() { form.submit(); } So is it possible to do this without JavaScript ? Dejan Kulpinski Sierra Systems (604) 688-1371/450

3 2

Zope Consulting in the UK?
by Ian Sparks 11 Mar '00

11 Mar '00

Hi, Being UK based myself I wondered if there are any UK Zopistas who work for web-design/application development houses? Do UK web-design shops have a clue about Zope? - Ian Sparks.

3 2

dtml-var behavior
by Sin Hang Kin 11 Mar '00

11 Mar '00

I got a quoted version of the object if I made <dtml-var this> It does not evaluate the tags and quoted all < with < and so they all showed on the browser. What rules determine when it will be quoted? Also, I got the same result if I have <dtml-var "folder.obj"> I can work around with <dtml-with folder> <dtml-var obj> </dtml-with> But how can I workaround "this"? Rgs, Kent Sin

2 1

ZClass, Base Classes and logic (QUEST)
by Oscar Picasso 11 Mar '00

11 Mar '00

Hi, Most of the time when someone complains about DTML syntax or the learning curve and so on, the answer is we should code our logic in python if we know this language. That's what I am trying to do because I love Python. However, many times I don't know how to import my logic in Zope. example: I wrote a very simple module MyTest.py: ################################## class SuperClass: def __init__(self): self.a='This is a in SuperClass' class MyClass(SuperClass): def __init__(self): SuperClass.__init__(self) self.b='This is b in Myclass' ################################## In the python interpreter I do the following things: >>>import MyTest >>>import MyTest.MyClass >>>t=MyTest.MyClass.MyClass() >>>t.a 'This is a in SuperClass' >>>t.b 'This is b in Myclass' That's what I expected. Now I intall the package in zope. I make a ZClass which only Base class in MyClass. Its metatype is MyClassClass, so it appears on the popup menu near the Add button. But when I try to add an instance I get the following message: Error Type: TypeError Error Value: unbound method must be called with class instance 1st argument I guess that the problem is the line SuperClass.__init__(self) ==>however I don't understand why it works fine with the python interpreter and why not in Zope. Others behaviors of Zope: suppose i add the following line in the MyClass __init__ function: self.d='I am d' No problem when I run it with the interpreter: >>>t.d 'I am d' In zope: <dtml-var "MyClassInstance.d"> renders: Error Type: AttributeError Error Value: d I get the right value of d only with the new instances of MyClass. On the other hand if MyClass has a property sheet, all the instances are updated if change the property sheet. ==>So again, why these differences in the behavior of ZClass instances depending of which part we modify (the python Base Class or the Zope ZClass)? I really love Zope but I prefer code in python. However I hit often the wall when I try to put the pieces together. I think that speaking about documentation : clear API docs would be, for me the most important. What behavior could I expect from the differents parts of Zope. Example of docs I find useful with other 'languages': Python Library Reference Java API documentation

2 1