Dear explorer,

You’re always so nice to me. You give me all kinds of useless javascript errors, if ever you give them rather than simply executing nothing without the slightest tell. You break all kinds of standards, you’re not even able to tell the difference between a border and a padding when you go to the length of using the width of an element (it should be easy enough to skin the first 20 pages of a specs for a team of developers; perhaps it is not). You don’t like the DOM, don’t like ECMAscript, you make us put ActiveX all around. for even the simplest task But yet, one thing I wonder: tell me why, if I put inside an element <input type=”checkbox” value=”/management”>, when I ask you back the content of the element you tell me it is <INPUT type=checkbox value=/management>, bringing my memories back to the terrific days of HTML 3?

Take care and burn in hell,

- RedGlow

Posted by mattia as html at 3:53 PM CEST

No Comments »

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

No Comments »