openerp-expert-framework team mailing list archive

[Nicolas Bessi <nicolas.bessi@xxxxxxxxxxxxxx>]

Hello  everybody,  

Raphaël thanks for your answer and you implication. 

My objective is not to generate any rendering or formatting, my explanation may not be clear (My english skills have to be improved). 
What we want to do is to provide an easier and more intuitive way to call wizzard and os_memory in the steps files of OERPScenario. 
The idea is to provide a class that will allows to have a more intuitive and generic way of calling wizzards and osv_memory in term of code. The goals is to be able to have an object instance that will allows call next wizard steps, osv_memory step, store steps and field call and set field value in the object and so forth in a more 'ruby active record' style, in order to have the writing of test more accessible.

We want to do this because when calling complexes wizards with OOOR in OERPscenario required quite heavy code. We just want to provide a nicer abstraction layer. But We will write a blueprint soon in order to share, discuss  our point of view.

I agree with you a Rails client for OpenERP will be HUUGEEE and I quite agree with you vision of the client architecture.  I see an enormous  potential in OOR and I'm already dreaming of a dynamic link with Spree ;)

+1
> and I don't want to give up Rails for CherryPy/Mochikit sorry 


Regards 

Nicolas 

Le 18 déc. 2009 à 16:24, Raphaël Valyi a écrit :

> Hello Nicolas (and all I added in copy),
> 
> Can you please explain better how it will differ from the current minimalist OpenObjectWizard wizard proxy here?
> http://github.com/rvalyi/ooor/blob/master/lib/app/models/open_object_ui.rb
> 
> 
> Basically my overall vision of the OOOR architecture is:
> 
> 1) we proxy all the Model layer of the OpenERP MVC architecture. There is currently a minimalist Controller support too, through the OpenObjectsController class here http://github.com/rvalyi/ooor/blob/master/lib/app/controllers/open_objects_controller.rb
> but it's minimalist currently, I and did it here only because it provide multiformat (XML, Json...) HTTP REST exposure to OpenERP business objects in no code.
> 
> 2) But, in my opinion, to modularize things properly, if we start implementing a full blown view layer and or the controller layer more fully, we better create an other GEM that will simply depend on OOOR. Ultimately, such a second GEM could be completed into a complete Rails OpenERP web client, at least we could dream about that. (the issue is that we all know how much the current Cherrypy web-client costs to Tiny, so full completion/browser compt would be a lot of work, I would need myself like full time 60/80 days to complete such a task, but granted, the client would be awesome and use standard know stuff. At least if you know somebody willing to fund it that would be a pleasure as long as we don't miss our entry on the Brazilian market for that...
> 
> 3) There is however a smarter path to this: let's add features incrementally as we need them and find funding. On the other side, I'm doing all I can to make sure the 5.2 clients of OpenERP could easily embbed a custom DHTML (eg iframe) widget, that could be implemented in OOOR to provide key sexy widgets as the user need them. That would allow creating an awesome OOOR web based product configurator for instance, with no widget/framework restriction as we have currently. At the same time, I'm also making sure we could embbed any OpenERP web-client form in a custom non OpenERP web application. That's pretty much what happen on the Odoo subsribtion page embedded in Tiny's Joomla. We have yet a few things to check, like easyness to pass a custom CSS and things like that...
> By the way, Tiny themselves are building a plugin architecture for the 5.2 web-client. That's very good but will still stick you with Python, Cherrypy and probably even Mochikit Javascript which might not be what you find the best or where you find the most productive developers. At least being open to other server technologies is a must have (else that would fail just like Java portlet failed, even worse).
> 
> 4) Wizards live somewhat in between these two worlds: they are highly tied to the user interface and are transient models at the same time. Not all MVC patterns are always cleanly decoupled and that's not necessarily bad. For instance, in Java Swing, the view and controller layers are pretty much tied together in the ui concept.
> For the minimal part of it, I pretty replicated that Swing component concept in OOOR, that's what explains the current classes you will find in
> http://github.com/rvalyi/ooor/blob/master/lib/app/models/open_object_ui.rb
> 
> 5) My idea is that, as long as we implement wizards and model support that is to be called programmatically (or via WS), we should make them part of OOOR just like http://github.com/rvalyi/ooor/blob/master/lib/app/models/open_object_ui.rb
> 
> So more might be required here and that's why I'm asking you what exactly are you thinking about. Currently my wizard proxy is such a transient object that can easily hold its transient state and pull/push it to OpenERP wizards. Notice that this 'form bean' ability is shared with views that do not persist across requests but that explains the current architecture.
> 
> Especially, more might be required for osv_memory wizards, well I never tried yet, may be that was what you were thinking about?
> 
> However, if you want to start using OOOR via a templating format (HTML, XML...) and enforce OpenERP views behavior, I propose we create an extra GEM layer to keep OOOR minimalist and clean.
> 
> 
> 
> All right, please precise your point. Meanwhile, I added you as a commiter so feel free to submit code directly; I'll double check it anyway.
> Finally, I consider Oescenario to be a key feature for OpenERP, so I'm committed to support you here as I share you hope of a complete readable/maintainable test suite for OpenERP as well as ability to package tests with custom modules as executables specs for some enlighted customers. I also make OOOR to be able to work around the UI limitations of the OpenERP web-client (and I don't want to give up Rails for CherryPy/Mochikit sorry) whenever a customer project requires it. Also, I should say it's fun.
> 
> 
> All right, enjoy OOOR 1.1.0 and let me know about issues/plans.
> 
> 
> -- 
> Raphaël Valyi
> http://www.akretion.com
> 
> 
> 
> 2009/12/18 Nicolas Bessi <nicolas.bessi@xxxxxxxxxxxxxx>
> Hello everybody,
> 
> We have decided to create a wizard Object Mapper in OERPScenario as we discussed with Raphaël some time ago (please refer to mail found below). It will be based on the wizard proxy that OOOR provide.it will allows to have a more easy and coherent API in OERPScenario. The question to discuss is  :
> Should this functionality  be provided  at the OpenERPScenario level or in an OOOR branch. If Raphaël agree with it,  we prefer to have it at the OOOR level in order to bring this functionality to more people.   
> 
> Regards 
> 
> Nicolas 
> 
> 
> 
> Le 11 nov. 2009 à 20:32, Raphaël Valyi a écrit :
> 
>> All right, regression http://github.com/rvalyi/ooor/issues/closed#issue/8  fixed by OOOR 1.0.8 GEM, please upgrade and let me know.
>> 
>> Thanks for the report and sorry for the inconvenience. I'll keep thinking about osv wizards, but no deadline promise. Still, I should be able to implement the generic class level method_missing during the week.
>> 
>> Raphaël
>> 
>> 
>> 2009/11/11 Raphaël Valyi <rvalyi@xxxxxxxxxxxx>
>> Hello,
>> 
>> I always knew I shouldn't have drink that capirinha at lunch...
>> Anyway, back to work, I'm correcting Joel's bug right now.
>> For the wizard thing, not sure yet. But in any case I was thinking about implementing a generic proxy for osv Class methods upon the OpenObjectResource method.
>> In OpenERP, ORM methods are actually mostly class methods and not instance methods, this is true also for wizard ORM methods.
>> So may be it will be enough.
>> The way to implement it will be by implementing method_missing not at the instance level as it is, but at the class level too.
>> I will just copy what is done in the web client in openerp/tools/rpc.py for that and it will replace the generic call method.
>> 
>> Now, of course, this is true, OOOR is handy because it adds instance methods: like res_partner.save which OpenERP gives not and sucks.
>> May be it would be handy to have those for wizards too.
>> 
>> Currently you can't use OOOR for osv_wizard classes? I should say I never tried but I don't really see why this wouldn't work as OSV methods just look the same.
>> Will look.
>> 
>> All right, fixing the one2many regression for now...
>> 
>> 
>> BTW, one day we could imagine a Rails web client upon the top on OOOR. My path however is progressive: after Rails 3 is out, ActiveResource will be more integrated with ActiveRecord, so validations will work for ActiveResource too (we should use things like Formastic for now if we wanted do this). Then we can first support editing OpenERP records in simple forms using OpenERP fields_view get. With the iframe widget I would like in OpenERP 5.2, we could use OOOR sometimes inside the OpenERP web client when the OpenERP framework is not good enough. Then we could eventually start completing the client and may be one day have a clean Rails client who knows...
>> 
>> 
>> Raphaël
>> 
>> 
>> 
>> 2009/11/11 Nicolas Bessi <nicolas.bessi@xxxxxxxxxxxxxx>
>> 
>> Hello,
>> 
>> I would like to provide an implementation for the wizards in Ooor.
>> 
>> Here is my proposition.
>> Create a new wizard class.
>> The contructor should receive model and wizard name.
>> The instance will contain the wizard id and the form fields, the possible actions and the model. It will also have a next_step function that will call the next wizard step retrieve the form and the possible actions.
>> 
>> I'm still not quite sure sure of the architecture. Should the wizard class ihneritw Active ressource or directly the ooor one...
>> 
>> Well I think we can discuss this point if you agree with the idea
>> 
>> Regards
>> 
>> Nicolas
> 
> 
> --------------------------------------------------------------------
> Camptocamp SA
> Nicolas Bessi 
> PSE A
> CH-1015 Lausanne
> www.camptocamp.com  / www.openerp.com  / www.mapfish.org
> 
> +41 21 619 10 26 (direct)
> +41 21 619 10 10 (centrale)
> +41 21 619 10 00 (fax)
> --------------------------------------------------------------------
> 



--------------------------------------------------------------------
Camptocamp SA
Nicolas Bessi 
PSE A
CH-1015 Lausanne
www.camptocamp.com  / www.openerp.com  / www.mapfish.org

+41 21 619 10 26 (direct)
+41 21 619 10 10 (centrale)
+41 21 619 10 00 (fax)
--------------------------------------------------------------------