Just as a reminder, the generic way to add an element to an object manager (like Folders) it’s:
<container>.manage_addProduct[’<product name>‘].<add method, usually manage_add*product name*>(arguments)
Posted by mattia as zope at 3:51 PM CET
Calendar
| « Oct |
|
Dec » |
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
Pages
Categories
Archives
Links
Just as a reminder, the generic way to add an element to an object manager (like Folders) it’s:
<container>.manage_addProduct[’<product name>‘].<add method, usually manage_add*product name*>(arguments)
Posted by mattia as zope at 3:51 PM CET
Well, I download the whole mootools library in compressed form, which is about 42kbytes of text all in a simple line (a big, big, big “eval”). I put into my Zope instance and go editing the object… pity for Firefox: it’s almost impossible, since loading such a big line in a textfield gives considerable problems to the browser, up to blocking it on my old notebook.
So, what to do?
Would you believe that the old, textual “links” program just loaded the whole thing without complaining the little?
In the Developer Book of Zope they tell you that if you put a README.txt file in the root directory of your brand new product, it’ll appear a new README tab in the Control Panel (not in the product’s instances, beware). Apart from the fact this isn’t really true (I suspect it looks for the existence of version.txt too; which, by the way, must be written something like “Product-x.x.x”, with the dash in the middle, to be recognized), it isn’t really true that any restructured text is accepted, at least in zope 2.10. The problem is that the normal way of writing sections like that doesn’t work:
Section 1
=========
Hello!
You must use indentation instead:
Section 1
[blank space]Hello!
And everything works ok. Oh, well, one more strange thing under the sun.
Posted by mattia as zope at 10:46 PM CEST
During the development of a Zope 2 product, I was in need on product construction to show in the Add form all the instances of another product in the same ZODB, to create a sort of “soft link” between them, so to use it. That is, I needed to do something like the SQLConnectionIDs method, but generalized to another object kind.
First problem: which method can make me search according to a certain metatype? digging a little in the code of the standard Find form, I discovered the ZopeFind method (OFS.FindSupport) which substantially is the true backend of the find operation, and thus support also the search by metatype.
Second problem: I have to call this method on the object I want to start search from, so I needed the root of the ZODB. This can either be done by the restrictedTraverse(’/') method, or the getPhysicalRoot() one. I discovered at first the second, which needs to be coded in python to have enough privileges to run (the first one can be called from any context). So, I wrote a python method in a product module which did the find operation, then I needed to call it from the ZPT of the add form. But, how to refer to that method? which is the context of that form? I discovered is the very same FactoryDispatcher (App.FactoryDispatcher) which is then passed to the creation method. But now, how could it help me?
Then I discovered a bit of information I always missed from any tutorial and explanation. In the registerClass method, the constructors parameter uses the first tuple element as a factory method. and the other parameters passed? well, they are passed to the above FactoryDispatcher, whose only aim is to create a temporary namespace (context) where to put objects the constructor needs. That’s why you usually put the constructor form (first argument, called) and the constructor function (since it will be referred to in the “action” parameter of your form, it will be searched in the context, which is the FactoryDispatcher, which knows your construction function because you passed it as a second argument). But this means you can also pass how many arguments you like: it’ll take their __name__ attribute, and map with that in the context.
That’s it: put the needed product method in the constructors parameter, and you can call it from the add form without problems.
Suggestion: for such a task, use a select form element, give the contained option elements the getPhysicalPath as value and getId as content; when the value comes back to the creation function, use the context.restrictedTraverse to get back the object.
Posted by mattia as zope at 4:16 PM CEST