Hello guys, I don't know if you got that, but my Ruby OOOR connector for OpenERP is able to draw UML diagrams of any OpenERP classes since version 1.2.3. It uses the ir_model and ir_model_fields table to draw the UML, meaning even fields.function are properly displayed unlike tools that just connect to the database schema.
Yes, there are the end users, but before dreaming about end users able to use OpenERP out of the box, I think it's good to make sure non alien tech people at least can grasp it. Then may be it will eventually mature enough into something accessible for the tech disabled guys too. So I think we could eventually attach such an UML drawing inside some modules. At least, for integrators, it's useful to know the command to quickly reverse engineer some module you don't know yet. Taktik.be started using it too and have fallen in love with it. It's specially space savy when drawing the relations, reusing the same borders for reverse relations (like one2many / many 2one or two sides many2many). However, you can't generally draw the whole UML: it's too large: you can't read it and it will even make an out of memory in dot. However, it's very useful to document a set of classes with their directly connex classes. I implemented it in OOOR because for me in Ruby it was a snap (I hadn't more time to waste), now if some Python red neck wants to rip the code and makes it an OpenERP module that document any OpenERP Object or collection of objects, then be my guest. Calling Ooor via a Python method inside an OpenERP module (ruby command line, just like when you call dot) would also be pretty easy and cross platform. The specific part of OOOR that draws UML is here: http://github.com/rvalyi/ooor/blob/master/lib/app/models/uml.rb It looks like it's larger than it should be. Actually it's because to save space, we collect all the relations first and then only draw them in a factored way. You can find such an example here: http://www.akretion.com/en/blog/2010/01/18/introducing-ooor---openobject-on-rails-drivingrequesting-your-openerp-became-a-child-play/ and the UML tutorial here: http://wiki.github.com/rvalyi/ooor/drawing-openerp-uml-diagrams-with-ooor Whole OOOR tutorial / API here: http://github.com/rvalyi/ooor In the future, I would like to implement serializing the schema in YAML. Then I could easily spot any schema change between two schemas. Meaning we could have a cool feature showing all the relational exertions brought by some module. So for instance in the UML diagram you would see in green all the new objects and newly added relations. That would be very handy to document modules then. I guess I need a half day to implement that properly (in OOOR). I hope I could do that over the next month. That could be especially cool if we had a function in module that would install the module, draw the UML and roll back the module installation. So you could know how a module looks like before installing. Next, I would like to be able to automatically spy the OpenERP trunk branch with a Robot (actually inside a Google Wave) and highlight all schema changes done since 5.0 release locally at each commit and also globally. I remember we talked about that with Fabien. I proposed him their devs would use a special commit flag like [SCHEMA_CHANGE] to highlight the data structure changes and make our migration life easier. He said he didn't want to change their process and would like this to be automated. Well they didn't do anything yet. But at least I'm close to that automated bot. I think in like one day and a half I could program such a Google Wave robot everyone could look at/subscribe and log additional comments such as community maintained migration scripts. Hope I find time soon. Let me know if you find OOOR UML useful. Raphaël Valyi http://www.akretion.com On Wed, Dec 30, 2009 at 2:48 PM, Cloves Almeida <[email protected]> wrote: > I support using rST. Documentation is boring enough, the easier to write, > the better :) > > > Albert Cervera i Areny escreveu: > >> A Dimarts, 15 de desembre de 2009, Albert Cervera i Areny va escriure: >> >> >> >>> A Dimecres, 9 de desembre de 2009, Albert Cervera i Areny va escriure: >>> >>> >>>> Here's a proposal I made some time ago. Given that now there's a >>>> framework expert's group, here's my second try: >>>> >>>> >>> After some discussions there seemed to be an agreement (at least nobody >>> objected) that at least a new documentation framework would be nice. I >>> have >>> implemented a first (early) draft and wanted to share what I have to >>> receive your feedback. With draft, I mean, that inheritance doesn't >>> work, >>> for example. >>> >>> >> >> I haven't had time to work on this by now, but I've been thinking a bit >> about it and I wanted to share my thoughts. >> >> One of the things that worries me about the module is that it's not very >> handy when one is developing a new module or writing a long text. rST seems >> to me a good tool for this. >> >> I think I'd be a must to have conversion tools between rST and the >> 'documentation' module I sketched. >> >> I envision, for example developers adding a "doc/" directory in the >> module. There they'd put .rst files which would be automatically uploaded to >> OpenERP just like it happens with views, for example. One of the things we'd >> need, though is the possibility of inheritance, and modifying other modules >> texts. Maybe we should force the creation of a manual ID (again, just like >> in views). For example: >> >> <cut> >> >> [invoicing_process_title] >> Invoicing Process >> ============== >> >> [invoicing_process_p1] >> The invoicing process works this way and not in another one and one must >> take into account the following things: >> >> [invoicing_process_items] >> - This is item number one >> - This is item number two >> >> </cut> >> >> Upload process should ensure that each paragraph has an ID and it's >> unique. We should force adding those IDs, otherwise, people inheriting the >> module wouldn't be able to properly hook documentation wherever they need. >> >> The previous fragment would create three records in table >> ir_documentation_paragraph. (The process should be able to upload images >> too, if they exist in the text.) The first one looking something like this: >> >> { >> 'identifier': 'invoicing_process_title', >> 'text': 'Invoicing Process', >> 'type': 'subsection', >> } >> >> Of course, writting new .rST files out of the records in the database >> should also be possible, and pretty easy to implement. >> >> Now, let's say we create a new module depending on the previous one (which >> was called 'account') and we need to append another item to the list. It >> could look something like this: >> >> <cut> >> >> [invoicing_process_item_new:account.invoicing_process_items:append] >> - This is item number three >> >> </cut> >> >> We could work with inherited elements similarly to what it's possible with >> views: >> >> replace -> Replaces the whole paragraph. >> after -> Adds the new element as a new paragraph after the inherited one >> before -> Adds the new element as a new paragraph before the inherited one >> append -> Adds the new element just after the inherited one. That is, >> without creating a new paragraph. >> >> All this ID stuff would also be used for translations, although those >> would be handled in .po files. >> >> Comments? >> >> >> > > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-expert-framework > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openerp-expert-framework > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
