osv.osv_memory wizards
Up until now I have managed to avoid wizards. I’ve always had a feeling that they would be useful, but with so much more to learn on other aspects, have left them alone. This is partly because I find that while I have half a clue what I’m doing, in most cases OpenERP assumes at least three-quarters when explaining things in their developer documentation. When it comes to wizards, it is even worse. I must have read that documentation 50 times and it is still useless. Even after successfully creating a wizard. 80% of the documentation refers to old style wizards, with 10% explaining new style, only in relation to res.config. Add on a bit of how to convert from old style to new style and you are left worse off than when you begin.
So now I’ll make it my mission to explain them more from a user/developer perspective. It’s going to be more than one post.
I think we should get another thing straight, I hate the terms old style and new style wizards. It makes it sound like a whole new syntax, methods, architecture to get to grips with. In the case of old style wizards, such as those in v5 – this is (probably) absolutely true. It also doesn’t help that the default folder name for these – thinking of a better name – Openerp memory objects, is wizard, and half the time their views are called wizard or even their name. That is a throwback to v5 and hopefully, like we saw the death of __terp__.py, once all the old style wizards are gone and everyone forgets their awfulness we can call the new style one just plain old wizards again. Until then it is confusing.
The documentation will tell you it is about a series of interactions between server and client. I kind of get that but they never really got to the crux of the matter. For me, you want to use a wizard when you want the user to define the parameters to be sent to a particular function. I use the term function loosely, this may be producing a report, updating the database, or anything else you can do in OpenERP.
Importantly, once it is finished, you no longer want that object instance/record. That is unlike standard osv.osv objects that are stored in our postgres database, osv.osv_memory objects are temporal and only exist in memory.
Other than that it all seems pretty much the same. Views, workflows (yet to really experiment but I have a couple of ideas), fields and functions are all the same. They can be assigned to menus, objects or called in code and aside from popping up a modal box instead of tab, you are probably using them and not knowing.
I would put a note there that because they exist only in memory, defining bi-directional relations with osv.osv objects is unwise at best, and I don’t really see the point of defining a one2many with an osv.osv object either even if it is one way. many2one and many2many uni-directional though are all good, and the many2many bridging table, at least as far as I can tell also only exists in memory. There isn’t a great deal of point of one2many in the main application I have used wizards for to date anyway, which is reporting, because you don’t want to create new records typically (at least not manually), it is about using existing osv.osv database records.
Anyhow, the next post will focus on using Wizards in Reporting