Hello, I've the pleasure to inform you that OOOR-1.3.1 has been released. Here is what is new since 1.2.8:
bugfix: - regression http://github.com/rvalyi/ooor/issues/closed#issue/30 REGRESSION in OOOR-1.2.8: ArgumentError: no id given - http://github.com/rvalyi/ooor/issues/closed#issue/28 always use Rails.logger if used in Rails, no matter if we are not in development mode - fixed a few conrner cases wizard issues, see "new" section new: - able to read polymorphic many2one relations (OpenERP 'reference' field) - stores default OOOR instance in Ooor.default_ooor when used with Rails, rather than the OOOR constant which as an issue when altering it. - auto-completion in smart IRB consoles such as JRuby jirb_swing, now even for wizard methods - refactored FormModel - possibility to call action methods directly, such as invoice.action_cancel_draft without any need to use Class method proxies - optimize inherited relations loading (more laziness) database management and non resources webservices: - added 'common' and 'db' OpenERP webservices (with auto-completion hooks) directly upon the ooor instance: ex: ooor.create('admin', 'my_base') to create a database. So I believe no webservice is missing, you'll never need to do an RPC call manually at all. - added old wizard feature to ooor instance, so you can do w = @ooor.old_wizard_step('base_setup.base_setup') and use the wizard then This makes it trivial to create and configure a full blown database in just a few lines of Ruby script, here to install manufacturing profile + French chart of account: require "rubygems" require "ooor" @ooor = Ooor.new(:url => 'http://localhost:8069/xmlrpc', :username => 'admin', :admin => 'admin') @ooor.create("admin", "ooor_test") #will take some time, OOOR will automatically poll the server for notification manufacturing_module_id = IrModuleModule.search([['name','=', 'profile_manufacturing']])[0] w = @ooor.old_wizard_step('base_setup.base_setup') w.company(:profile => manufacturing_module_id) w.update(:name => 'Akretion.com', :state_id => false) w.finish @ooor.load_models #will create AccountConfigWizard and WizardMultiChartsAccounts proxies chart_module_id = IrModuleModule.search([['category_id', '=', 'Account Charts'], ['name','=', 'l10n_fr']])[0] w2 = AccountConfigWizard.create(:charts => chart_module_id) w2.action_create w3 = WizardMultiChartsAccounts.create w3.action_create OOOR also now comes with extensive RSpec unit tests (44 tests, more than 2000 webservices calls, probably +80% coverage): http://github.com/rvalyi/ooor/blob/master/spec/ooor_spec.rb You can read that to understand the full API (will update the project doc soon to). In any case, as you can see you don't need to understand Ruby to understand some OOOR code. In conclusion, we want OOOR to be usable seamlessly by the Cucumber functional test folks (OERPScenario) without having any bug/regressions. Cucumber has the advantage of plain English readable tests that can be written in first place by non tech guys (and then made working by tech folks). Now, I should say, if a techy guy want to write some test, I think RSpec is perfectly valid, it's faster and more terse to code as you can see. And it's perfectly readable too. So feel free to abuse RSpec to if you don't need a tech disable guy in the chain, use Cucumber (OERPScenario) otherwise. The good news is that a Cucumber test can perfectly trigger an RSpec test, it has been thought for it... Finally, OOOR 1.3.1 comes with some very experimental Client interface code that is able to render in text mode, menu items in form or tree view. This is a first step toward a full blown Rails3 web-clients. Next steps are (timeline assuming us contributing freely in spare time, any contract with us would speed things dramatically of course): - implement a to_html methods for the FormView object rather then just to_s. Get it working for an increasingly larger set of widget, using module inclusion for custom pluggability. Thus in a month or so it will be easy to ebbed some arbitrary OpenERP form or tree view inside a Rails site (you could also already proxy the Python web-client), at least in read only mode and for the simplest views. Consider if GWT (via JRuby) would be an option or not to benefit mature/optimized widgets, but Franckly JQuery might have them too. - implement Rails3 ActiveModel interface and get form edition working (in 2 months ?) - complete the menu/cross component navigation to have a basic HTML layout + tree/form view edition (in 4 months?) - then it would all depend how the community or OpenERP S.A. considers this option. Akretion will not assume to develop a full blown Rails3 web-client for free alone, it's just too much work, even if using smart/standard Javascript libs, can make it a fraction of the Python web-client. Our goal is to make it easy for a Rails site to use OpenERP stuff. This could include improving the Python web client with a Rack Rails reverse proxy (ex: you code your product configurator in Rails OOOR and inject it in the web-client view in place of some determined widget). At the same time we will show the world how close we can go from a full blown top notch web-client technology with little and clean tested code. If ever the idea picks up, then it would be a reality too, else would stay a quick done prototype. Enjoy! ------------------------ Raphaël Valyi CEO and OpenERP consultant at http://www.akretion.com -------------------- m2f -------------------- -- http://www.openobject.com/forum/viewtopic.php?p=52563#52563 -------------------- m2f --------------------
_______________________________________________ Tinyerp-users mailing list http://tiny.be/mailman2/listinfo/tinyerp-users
