Vous êtes sur la page 1sur 16

03/12/13

Building an OpenERP Web module

Applications (https://www.openerp.com/apps)
(https://www.openerp.com/)

Partners (https://www.openerp.com/partners/directory) Training (https://www.openerp.com/events#view=training) Free Trial (https://www.openerp.com/start) Download (https://www.openerp.com/start?download) Contact Us (https://www.openerp.com/contact) Sign In (https://accounts.openerp.com)

Navigation Navigation
Building an OpenERP Web module

Building an OpenERP Web module


There is no significant distinction between an OpenERP Web module and an OpenERP module, the web part is mostly additional data and code inside a regular OpenERP module. This allows providing more seamless features by integrating your module deeper into the web client.

Table Of Contents (../)


Building an OpenERP Web module A Basic Module Web Declaration Getting Things Done Paint it black Burning through the skies Mic check, is this working?

A Basic Module
A very basic OpenERP module structure will be our starting point:
w e b _ e x a m p l e _ _ i n i t _ _ . p y _ _ o p e n e r p _ _ . p y

Versions trunk server (/trunk/server/) web (/trunk/web/) crm (/trunk/crm/) hr_recruitment (/trunk/hr_recruitment/) project_issue (/trunk/project_issue/) mail (/trunk/mail/) mass_mailing (/trunk/mass_mailing/) email_template (/trunk/email_template/) project (/trunk/project/) hr_holidays (/trunk/hr_holidays/) training (/trunk/training/) 7.0 (/7.0/) de (/7.0/de/) es (/7.0/es/) fr (/7.0/fr/) it (/7.0/it/) ja (/7.0/ja/) pl (/7.0/pl/) pt_BR (/7.0/pt_BR/) ro (/7.0/ro/) ru (/7.0/ru/)

section
__init__.py __openerp__.py

diff

file

#_ _ o p e n e r p _ _ . p y { ' n a m e ' :" W e bE x a m p l e " , ' d e s c r i p t i o n ' :" B a s i ce x a m p l eo fa( f u t u r e )w e bm o d u l e " , ' c a t e g o r y ' :' H i d d e n ' , ' d e p e n d s ' :[ ' b a s e ' ] , }

This is a sufficient minimal declaration of a valid OpenERP module.

Web Declaration
There is no such thing as a "web module" declaration. An OpenERP module is automatically recognized as "web-enabled" if it contains a s t a t i c directory at its root, so:
w e b _ e x a m p l e _ _ i n i t _ _ . p y _ _ o p e n e r p _ _ . p y s t a t i c

is the extent of it. You should also change the dependency to list w e b: section
__openerp__.py ' n a m e ' :" W e bE x a m p l e " , ' d e s c r i p t i o n ' :" B a s i ce x a m p l eo fa( f u t u r e )w e bm o d u l e " , ' c a t e g o r y ' :' H i d d e n ' , ' d e p e n d s ' :[ ' w e b ' ] , }

diff

file

Note This does not matter in normal operation so you may not realize it's wrong (the web module does the loading of everything else, so it can only be loaded), but when e.g. testing the loading

https://doc.openerp.com/trunk/web/module/

1/16

03/12/13

Building an OpenERP Web module

tr (/7.0/tr/) vi (/7.0/vi/) zh_CN (/7.0/zh_CN/) 6.1 (/6.1/) de (/6.1/de/) es (/6.1/es/) fr (/6.1/fr/) it (/6.1/it/) ja (/6.1/ja/) pl (/6.1/pl/) pt_BR (/6.1/pt_BR/) ro (/6.1/ro/) ru (/6.1/ru/) tr (/6.1/tr/) vi (/6.1/vi/) zh_CN (/6.1/zh_CN/) 6.0 (/6.0/) de (/6.0/de/) es (/6.0/es/) fr (/6.0/fr/) it (/6.0/it/) ja (/6.0/ja/) pl (/6.0/pl/) pt_BR (/6.0/pt_BR/) ro (/6.0/ro/) ru (/6.0/ru/) tr (/6.0/tr/) vi (/6.0/vi/) zh_CN (/6.0/zh_CN/) 5.0 (/5.0/) de (/5.0/de/) es (/5.0/es/) fr (/5.0/fr/) it (/5.0/it/) ja (/5.0/ja/) pl (/5.0/pl/) pt_BR (/5.0/pt_BR/) ro (/5.0/ro/) ru (/5.0/ru/) tr (/5.0/tr/) vi (/5.0/vi/) zh_CN (/5.0/zh_CN/)

process is slightly different than normal, and incorrect dependency may lead to broken code. This makes the "web" discovery system consider the module as having a "web part", and check if it has web controllers to mount or javascript files to load. The content of the s t a t i c / folder is also automatically made available to web browser at the URL $ m o d u l e n a m e / s t a t i c / $ f i l e p a t h. This is sufficient to provide pictures (of cats, usually) through your module. However there are still a few more steps to running javascript code.

Getting Things Done


The first one is to add javascript code. It's customary to put it in s t a t i c / s r c / j s, to have room for e.g. other file types, or third-party libraries. section diff file

static/src/js/first_module.js / /s t a t i c / s r c / j s / f i r s t _ m o d u l e . j s c o n s o l e . l o g ( " D e b u gs t a t e m e n t :f i l el o a d e d " ) ;

The client won't load any file unless specified, thus the new file should be listed in the module's manifest file, under a new key j s (a list of file names, or glob patterns): section
__openerp__.py ' d e s c r i p t i o n ' :" B a s i ce x a m p l eo fa( f u t u r e )w e bm o d u l e " , ' c a t e g o r y ' :' H i d d e n ' , ' d e p e n d s ' :[ ' w e b ' ] , ' j s ' :[ ' s t a t i c / s r c / j s / f i r s t _ m o d u l e . j s ' ] , }

diff

file

At this point, if the module is installed and the client reloaded the message should appear in your browser's development console. Note Because the manifest file has been edited, you will have to restart the OpenERP server itself for it to be taken in account. You may also want to open your browser's console before reloading, depending on the browser messages printed while the console is closed may not work or may not appear after opening it. Note If the message does not appear, try cleaning your browser's caches and ensure the file is correctly loaded from the server logs or the "resources" tab of your browser's developers tools.

Download free E-books At this point the code runs, but it runs only once when the module is initialized, and it can't get (https://www.openerp.com/ebooks) access to the various APIs of the web client (such as making RPC requests to the server). This is done by providing a javascript module (http://addyosmani.com/resources/essentialjsdesignpatterns/book/#modulepatternjavascript): Start your free trial (https://www.openerp.com/start) section diff file

static/src/js/first_module.js / /s t a t i c / s r c / j s / f i r s t _ m o d u l e . j s o p e n e r p . w e b _ e x a m p l e=f u n c t i o n( i n s t a n c e ){ c o n s o l e . l o g ( " M o d u l el o a d e d " ) ; } ;

If you reload the client, you'll see a message in the console exactly as previously. The differences, though invisible at this point, are: All javascript files specified in the manifest (only this one so far) have been fully loaded An instance of the web client and a namespace inside that instance (with the same name as the module) have been created and are available for use

https://doc.openerp.com/trunk/web/module/

2/16

03/12/13

Building an OpenERP Web module

The latter point is what the i n s t a n c e parameter to the function provides: an instance of the OpenERP Web client, with the contents of all the new module's dependencies loaded in and initialized. These are the entry points to the web client's APIs. To demonstrate, let's build a simple client action (../client_action/): a stopwatch First, the action declaration: section
__openerp__.py ' d e s c r i p t i o n ' :" B a s i ce x a m p l eo fa( f u t u r e )w e bm o d u l e " , ' c a t e g o r y ' :' H i d d e n ' , ' d e p e n d s ' :[ ' w e b ' ] , ' d a t a ' :[ ' w e b _ e x a m p l e . x m l ' ] , ' j s ' :[ ' s t a t i c / s r c / j s / f i r s t _ m o d u l e . j s ' ] , } web_example.xml < ! -w e b _ e x a m p l e / w e b _ e x a m p l e . x m l> < o p e n e r p > < d a t a > < r e c o r dm o d e l = " i r . a c t i o n s . c l i e n t "i d = " a c t i o n _ c l i e n t _ e x a m p l e " > < f i e l dn a m e = " n a m e " > E x a m p l eC l i e n tA c t i o n < / f i e l d > < f i e l dn a m e = " t a g " > e x a m p l e . a c t i o n < / f i e l d > < / r e c o r d > < m e n u i t e ma c t i o n = " a c t i o n _ c l i e n t _ e x a m p l e " i d = " m e n u _ c l i e n t _ e x a m p l e " / > < / d a t a > < / o p e n e r p >

diff

file

then set up the client action hook (../client_action/) to register a function (for now): section diff file

static/src/js/first_module.js / /s t a t i c / s r c / j s / f i r s t _ m o d u l e . j s o p e n e r p . w e b _ e x a m p l e=f u n c t i o n( i n s t a n c e ){ i n s t a n c e . w e b . c l i e n t _ a c t i o n s . a d d ( ' e x a m p l e . a c t i o n ' ,' i n s t a n c e . w e b _ e x a m p l e . a c t i o n ' ) ; i n s t a n c e . w e b _ e x a m p l e . a c t i o n=f u n c t i o n( p a r e n t ,a c t i o n ){ c o n s o l e . l o g ( " E x e c u t e dt h ea c t i o n " ,a c t i o n ) ; } ; } ;

Updating the module (in order to load the XML description) and re-starting the server should display a new menu Example Client Action at the top-level. Opening said menu will make the message appear, as usual, in the browser's console.

Paint it black
The next step is to take control of the page itself, rather than just print little messages in the console. This we can do by replacing our client action function by a Widget (../widget/). Our widget will simply use its s t a r t ( ) to add some content to its DOM: section diff file

static/src/js/first_module.js / /s t a t i c / s r c / j s / f i r s t _ m o d u l e . j s o p e n e r p . w e b _ e x a m p l e=f u n c t i o n( i n s t a n c e ){ i n s t a n c e . w e b . c l i e n t _ a c t i o n s . a d d ( ' e x a m p l e . a c t i o n ' ,' i n s t a n c e . w e b _ e x a m p l e . A c t i o n ' ) ; i n s t a n c e . w e b _ e x a m p l e . A c t i o n=i n s t a n c e . w e b . W i d g e t . e x t e n d ( { c l a s s N a m e :' o e _ w e b _ e x a m p l e ' , s t a r t :f u n c t i o n( ){ t h i s . $ e l . t e x t ( " H e l l o ,w o r l d ! " ) ; r e t u r nt h i s . _ s u p e r ( ) ; } } ) ; } ;

https://doc.openerp.com/trunk/web/module/

3/16

03/12/13

Building an OpenERP Web module

after reloading the client (to update the javascript file), instead of printing to the console the menu item clears the whole screen and displays the specified message in the page. Since we've added a class on the widget's DOM root (../widget/#widget-dom-root) we can now see how to add a stylesheet to a module: first create the stylesheet file: section diff file

static/src/css/web_example.css . o p e n e r p. o e _ w e b _ e x a m p l e{ c o l o r :w h i t e ; b a c k g r o u n d c o l o r :b l a c k ; h e i g h t :1 0 0 % ; f o n t s i z e :4 0 0 % ; }

then add a reference to the stylesheet in the module's manifest (which will require restarting the OpenERP Server to see the changes, as usual): section
__openerp__.py ' d e p e n d s ' :[ ' w e b ' ] , ' d a t a ' :[ ' w e b _ e x a m p l e . x m l ' ] , ' j s ' :[ ' s t a t i c / s r c / j s / f i r s t _ m o d u l e . j s ' ] , ' c s s ' :[ ' s t a t i c / s r c / c s s / w e b _ e x a m p l e . c s s ' ] , }

diff

file

the text displayed by the menu item should now be huge, and white-on-black (instead of small and black-on-white). From there on, the world's your canvas. Note Prefixing CSS rules with both . o p e n e r p (to ensure the rule will apply only within the confines of the OpenERP Web client) and a class at the root of your own hierarchy of widgets is strongly recommended to avoid "leaking" styles in case the code is running embedded in an other web page, and does not have the whole screen to itself. So far we haven't built much (any, really) DOM content. It could all be done in s t a r t ( ) but that gets unwieldy and hard to maintain fast. It is also very difficult to extend by third parties (trying to add or change things in your widgets) unless broken up into multiple methods which each perform a little bit of the rendering. The first way to handle this method is to delegate the content to plenty of sub-widgets, which can be individually overridden. An other method [1] is to use a template (http://en.wikipedia.org/wiki/Web_template) to render a widget's DOM. OpenERP Web's template language is QWeb (../qweb/). Although any templating engine can be used (e.g. mustache (http://mustache.github.com/) or _.template (http://underscorejs.org/#template)) QWeb has important features which other template engines may not provide, and has special integration to OpenERP Web widgets. Adding a template file is similar to adding a style sheet: section
__openerp__.py ' d a t a ' :[ ' w e b _ e x a m p l e . x m l ' ] , ' j s ' :[ ' s t a t i c / s r c / j s / f i r s t _ m o d u l e . j s ' ] , ' c s s ' :[ ' s t a t i c / s r c / c s s / w e b _ e x a m p l e . c s s ' ] , ' q w e b ' :[ ' s t a t i c / s r c / x m l / w e b _ e x a m p l e . x m l ' ] , } static/src/xml/web_example.xml

diff

file

https://doc.openerp.com/trunk/web/module/

4/16

03/12/13

Building an OpenERP Web module

< t e m p l a t e s > < d i vt n a m e = " w e b _ e x a m p l e . a c t i o n "c l a s s = " o e _ w e b _ e x a m p l eo e _ w e b _ e x a m p l e _ s t o p p e d " > < h 4c l a s s = " o e _ w e b _ e x a m p l e _ t i m e r " > 0 0 : 0 0 : 0 0 < / h 4 > < pc l a s s = " o e _ w e b _ e x a m p l e _ s t a r t " > < b u t t o nt y p e = " b u t t o n " > S t a r t < / b u t t o n > < / p > < pc l a s s = " o e _ w e b _ e x a m p l e _ s t o p " > < b u t t o nt y p e = " b u t t o n " > S t o p < / b u t t o n > < / p > < / d i v > < / t e m p l a t e s >

The template can then easily be hooked in the widget: section diff file

static/src/js/first_module.js o p e n e r p . w e b _ e x a m p l e=f u n c t i o n( i n s t a n c e ){ i n s t a n c e . w e b . c l i e n t _ a c t i o n s . a d d ( ' e x a m p l e . a c t i o n ' ,' i n s t a n c e . w e b _ e x a m p l e . A c t i o n ' ) ; i n s t a n c e . w e b _ e x a m p l e . A c t i o n=i n s t a n c e . w e b . W i d g e t . e x t e n d ( { t e m p l a t e :' w e b _ e x a m p l e . a c t i o n ' } ) ; } ;

And finally the CSS can be altered to style the new (and more complex) template-generated DOM, rather than the code-generated one: section diff file

static/src/css/web_example.css c o l o r :w h i t e ; b a c k g r o u n d c o l o r :b l a c k ; h e i g h t :1 0 0 % ; } . o p e n e r p. o e _ w e b _ e x a m p l eh 4{ m a r g i n :0 ; f o n t s i z e :2 0 0 % ; } . o p e n e r p. o e _ w e b _ e x a m p l e . o e _ w e b _ e x a m p l e _ s t a r t e d. o e _ w e b _ e x a m p l e _ s t a r tb u t t o n , . o p e n e r p. o e _ w e b _ e x a m p l e . o e _ w e b _ e x a m p l e _ s t o p p e d. o e _ w e b _ e x a m p l e _ s t o pb u t t o n{ d i s p l a y :n o n e }

Note The last section of the CSS change is an example of "state classes": a CSS class (or set of classes) on the root of the widget, which is toggled when the state of the widget changes and can perform drastic alterations in rendering (usually showing/hiding various elements). This pattern is both fairly simple (to read and understand) and efficient (because most of the hard work is pushed to the browser's CSS engine, which is usually highly optimized, and done in a single repaint after toggling the class). The last step (until the next one) is to add some behavior and make our stopwatch watch. First hook some events on the buttons to toggle the widget's state: section diff file

static/src/js/first_module.js

https://doc.openerp.com/trunk/web/module/

5/16

03/12/13

Building an OpenERP Web module

o p e n e r p . w e b _ e x a m p l e=f u n c t i o n( i n s t a n c e ){ i n s t a n c e . w e b . c l i e n t _ a c t i o n s . a d d ( ' e x a m p l e . a c t i o n ' ,' i n s t a n c e . w e b _ e x a m p l e . A c t i o n ' ) ; i n s t a n c e . w e b _ e x a m p l e . A c t i o n=i n s t a n c e . w e b . W i d g e t . e x t e n d ( { t e m p l a t e :' w e b _ e x a m p l e . a c t i o n ' , e v e n t s :{ ' c l i c k. o e _ w e b _ e x a m p l e _ s t a r tb u t t o n ' :' w a t c h _ s t a r t ' , ' c l i c k. o e _ w e b _ e x a m p l e _ s t o pb u t t o n ' :' w a t c h _ s t o p ' } , w a t c h _ s t a r t :f u n c t i o n( ){ t h i s . $ e l . a d d C l a s s ( ' o e _ w e b _ e x a m p l e _ s t a r t e d ' ) . r e m o v e C l a s s ( ' o e _ w e b _ e x a m p l e _ s t o p p e d ' ) ; } , w a t c h _ s t o p :f u n c t i o n( ){ t h i s . $ e l . r e m o v e C l a s s ( ' o e _ w e b _ e x a m p l e _ s t a r t e d ' ) . a d d C l a s s ( ' o e _ w e b _ e x a m p l e _ s t o p p e d ' ) ; } , } ) ; } ;

This demonstrates the use of the "events hash" and event delegation to declaratively handle events on the widget's DOM. And already changes the button displayed in the UI. Then comes some actual logic: section diff file

static/src/js/first_module.js ' c l i c k. o e _ w e b _ e x a m p l e _ s t a r tb u t t o n ' :' w a t c h _ s t a r t ' , ' c l i c k. o e _ w e b _ e x a m p l e _ s t o pb u t t o n ' :' w a t c h _ s t o p ' } , i n i t :f u n c t i o n( ){ t h i s . _ s u p e r . a p p l y ( t h i s ,a r g u m e n t s ) ; t h i s . _ s t a r t=n u l l ; t h i s . _ w a t c h=n u l l ; } , u p d a t e _ c o u n t e r :f u n c t i o n( ){ v a rh ,m ,s ; / /S u b t r a c t i n gj a v a s c r i p td a t e sr e t u r n st h ed i f f e r e n c ei nm i l l i s e c o n d s v a rd i f f=n e wD a t e ( )-t h i s . _ s t a r t ; s=d i f f/1 0 0 0 ; m=M a t h . f l o o r ( s/6 0 ) ; s=6 0 * m ; h=M a t h . f l o o r ( m/6 0 ) ; m=6 0 * h ; t h i s . $ ( ' . o e _ w e b _ e x a m p l e _ t i m e r ' ) . t e x t ( _ . s t r . s p r i n t f ( " % 0 2 d : % 0 2 d : % 0 2 d " ,h ,m ,s ) ) ; } , w a t c h _ s t a r t :f u n c t i o n( ){ t h i s . $ e l . a d d C l a s s ( ' o e _ w e b _ e x a m p l e _ s t a r t e d ' ) . r e m o v e C l a s s ( ' o e _ w e b _ e x a m p l e _ s t o p p e d ' ) ; t h i s . _ s t a r t=n e wD a t e ( ) ; / /U p d a t et h eU It ot h ec u r r e n tt i m e t h i s . u p d a t e _ c o u n t e r ( ) ; / /U p d a t et h ec o u n t e ra t3 0F P S( 3 3 m s / f r a m e ) t h i s . _ w a t c h=s e t I n t e r v a l ( t h i s . p r o x y ( ' u p d a t e _ c o u n t e r ' ) , 3 3 ) ; } , w a t c h _ s t o p :f u n c t i o n( ){ c l e a r I n t e r v a l ( t h i s . _ w a t c h ) ; t h i s . u p d a t e _ c o u n t e r ( ) ; t h i s . _ s t a r t=t h i s . _ w a t c h=n u l l ; t h i s . $ e l . r e m o v e C l a s s ( ' o e _ w e b _ e x a m p l e _ s t a r t e d ' ) . a d d C l a s s ( ' o e _ w e b _ e x a m p l e _ s t o p p e d ' ) ; } , d e s t r o y :f u n c t i o n( ){ i f( t h i s . _ w a t c h ){ c l e a r I n t e r v a l ( t h i s . _ w a t c h ) ; } t h i s . _ s u p e r ( ) ; } } ) ; } ;

https://doc.openerp.com/trunk/web/module/

6/16

03/12/13

Building an OpenERP Web module

An initializer (the i n i t method) is introduced to set-up a few internal variables: _ s t a r t will hold the start of the timer (as a javascript Date object), and _ w a t c h will hold a ticker to update the interface regularly and display the "current time".
u p d a t e _ c o u n t e r is in charge of taking the time difference between "now" and _ s t a r t, formatting as H H : M M : S S and displaying the result on screen. w a t c h _ s t a r t is augmented to initialize _ s t a r t with its value and set-up the update of the counter display every 33ms. w a t c h _ s t o p disables the

updater, does a final update of the counter display and resets

everything. Finally, because javascript Interval and Timeout objects execute "outside" the widget, they will keep going even after the widget has been destroyed (especially an issue with intervals as they repeat indefinitely). So _ w a t c h must be cleared when the widget is destroyed (then the _ s u p e r must be called as well in order to perform the "normal" widget cleanup). Starting and stopping the watch now works, and correctly tracks time since having started the watch, neatly formatted.

Burning through the skies


All work so far has been "local" outside of the original impetus provided by the client action: the widget is self-contained and, once started, does not communicate with anything outside itself. Not only that, but it has no persistence: if the user leaves the stopwatch screen (to go and see his inbox, or do some well-deserved accounting, for instance) whatever was being timed will be lost. To prevent this irremediable loss, we can use OpenERP's support for storing data as a model, allowing so that we don't lose our data and can later retrieve, query and manipulate it. First let's create a basic OpenERP model in which our data will be stored: section
__init__.py #_ _ i n i t _ _ . p y f r o mo p e n e r p . o s vi m p o r to r m ,f i e l d s

diff

file

c l a s sT i m e s ( o r m . M o d e l ) : _ n a m e=' w e b _ e x a m p l e . s t o p w a t c h ' _ c o l u m n s={ ' t i m e ' :f i e l d s . i n t e g e r ( " T i m e " ,r e q u i r e d = T r u e , h e l p = " M e a s u r e dt i m ei nm i l l i s e c o n d s " ) , ' u s e r _ i d ' :f i e l d s . m a n y 2 o n e ( ' r e s . u s e r s ' ," U s e r " ,r e q u i r e d = T r u e , h e l p = " U s e rw h or e g i s t e r e dt h em e a s u r e m e n t " ) }

then let's add saving times to the database every time the stopwatch is stopped, using t h e " h i g h l e v e l " M o d e l A P I (../rpc/#openerp.web.Model.call): section diff file

static/src/js/first_module.js t h i s . _ s t a r t=n u l l ; t h i s . _ w a t c h=n u l l ; } , c u r r e n t :f u n c t i o n( ){ / /S u b t r a c t i n gj a v a s c r i p td a t e sr e t u r n st h ed i f f e r e n c ei nm i l l i s e c o n d s r e t u r nn e wD a t e ( )-t h i s . _ s t a r t ; } , u p d a t e _ c o u n t e r :f u n c t i o n( t i m e ){ v a rh ,m ,s ; s=t i m e/1 0 0 0 ; m=M a t h . f l o o r ( s/6 0 ) ; s=6 0 * m ; h=M a t h . f l o o r ( m/6 0 ) ;

https://doc.openerp.com/trunk/web/module/

7/16

03/12/13

Building an OpenERP Web module

. r e m o v e C l a s s ( ' o e _ w e b _ e x a m p l e _ s t o p p e d ' ) ; t h i s . _ s t a r t=n e wD a t e ( ) ; / /U p d a t et h eU It ot h ec u r r e n tt i m e t h i s . u p d a t e _ c o u n t e r ( t h i s . c u r r e n t ( ) ) ; / /U p d a t et h ec o u n t e ra t3 0F P S( 3 3 m s / f r a m e ) t h i s . _ w a t c h=s e t I n t e r v a l ( f u n c t i o n( ){ t h i s . u p d a t e _ c o u n t e r ( t h i s . c u r r e n t ( ) ) ; } . b i n d ( t h i s ) , 3 3 ) ; } , w a t c h _ s t o p :f u n c t i o n( ){ c l e a r I n t e r v a l ( t h i s . _ w a t c h ) ; v a rt i m e=t h i s . c u r r e n t ( ) ; t h i s . u p d a t e _ c o u n t e r ( t i m e ) ; t h i s . _ s t a r t=t h i s . _ w a t c h=n u l l ; t h i s . $ e l . r e m o v e C l a s s ( ' o e _ w e b _ e x a m p l e _ s t a r t e d ' ) . a d d C l a s s ( ' o e _ w e b _ e x a m p l e _ s t o p p e d ' ) ; n e wi n s t a n c e . w e b . M o d e l ( ' w e b _ e x a m p l e . s t o p w a t c h ' ) . c a l l ( ' c r e a t e ' ,[ { u s e r _ i d :i n s t a n c e . s e s s i o n . u i d , t i m e :t i m e , } ] ) ; } , d e s t r o y :f u n c t i o n( ){ i f( t h i s . _ w a t c h ){

A look at the "Network" tab of your preferred browser's developer tools while playing with the stopwatch will show that the save (creation) request is indeed sent (and replied to, even though we're ignoring the response at this point). These saved data should now be loaded and displayed when first opening the action, so the user can see his previously recorded times. This is done by overloading the model's s t a r t method: the purpose of s t a r t ( ) is to perform asynchronous initialization steps, so the rest of the web client knows to "wait" and gets a readiness signal. In this case, it will fetch the data recorded previously using the Q u e r y ( ) (../rpc/#openerp.web.Query) interface and add this data to an ordered list added to the widget's template: section diff file

static/src/js/first_module.js

https://doc.openerp.com/trunk/web/module/

8/16

03/12/13

Building an OpenERP Web module

t h i s . _ s u p e r . a p p l y ( t h i s ,a r g u m e n t s ) ; t h i s . _ s t a r t=n u l l ; t h i s . _ w a t c h=n u l l ; t h i s . m o d e l=n e wi n s t a n c e . w e b . M o d e l ( ' w e b _ e x a m p l e . s t o p w a t c h ' ) ; } , s t a r t :f u n c t i o n( ){ v a rd i s p l a y=t h i s . d i s p l a y _ r e c o r d . b i n d ( t h i s ) ; r e t u r nt h i s . m o d e l . q u e r y ( ) . f i l t e r ( [ [ ' u s e r _ i d ' ,' = ' ,i n s t a n c e . s e s s i o n . u i d ] ] ) . a l l ( ) . d o n e ( f u n c t i o n( r e c o r d s ){ _ ( r e c o r d s ) . e a c h ( d i s p l a y ) ; } ) ; } , c u r r e n t :f u n c t i o n( ){ / /S u b t r a c t i n gj a v a s c r i p td a t e sr e t u r n st h ed i f f e r e n c ei nm i l l i s e c o n d s r e t u r nn e wD a t e ( )-t h i s . _ s t a r t ; } , d i s p l a y _ r e c o r d :f u n c t i o n( r e c o r d ){ $ ( ' < l i > ' ) . t e x t ( t h i s . f o r m a t _ t i m e ( r e c o r d . t i m e ) ) . a p p e n d T o ( t h i s . $ ( ' . o e _ w e b _ e x a m p l e _ s a v e d ' ) ) ; } , f o r m a t _ t i m e :f u n c t i o n( t i m e ){ v a rh ,m ,s ; s=t i m e/1 0 0 0 ; m=M a t h . f l o o r ( s/6 0 ) ; s=6 0 * m ; h=M a t h . f l o o r ( m/6 0 ) ; m=6 0 * h ; r e t u r n_ . s t r . s p r i n t f ( " % 0 2 d : % 0 2 d : % 0 2 d " ,h ,m ,s ) ; } , u p d a t e _ c o u n t e r :f u n c t i o n( t i m e ){ t h i s . $ ( ' . o e _ w e b _ e x a m p l e _ t i m e r ' ) . t e x t ( t h i s . f o r m a t _ t i m e ( t i m e ) ) ; } , w a t c h _ s t a r t :f u n c t i o n( ){ t h i s . $ e l . a d d C l a s s ( ' o e _ w e b _ e x a m p l e _ s t a r t e d ' )

t h i s . _ s t a r t=t h i s . _ w a t c h=n u l l ; t h i s . $ e l . r e m o v e C l a s s ( ' o e _ w e b _ e x a m p l e _ s t a r t e d ' ) . a d d C l a s s ( ' o e _ w e b _ e x a m p l e _ s t o p p e d ' ) ; t h i s . m o d e l . c a l l ( ' c r e a t e ' ,[ { u s e r _ i d :i n s t a n c e . s e s s i o n . u i d , t i m e :t i m e , } ] ) ; static/src/xml/web_example.xml < pc l a s s = " o e _ w e b _ e x a m p l e _ s t o p " > < b u t t o nt y p e = " b u t t o n " > S t o p < / b u t t o n > < / p > < o lc l a s s = " o e _ w e b _ e x a m p l e _ s a v e d " > < / o l > < / d i v > < / t e m p l a t e s >

And for consistency's sake (so that the display a user leaves is pretty much the same as the one he comes back to), newly created records should also automatically be added to the list: section diff file

static/src/js/first_module.js

https://doc.openerp.com/trunk/web/module/

9/16

03/12/13

Building an OpenERP Web module

3 3 ) ; } , w a t c h _ s t o p :f u n c t i o n( ){ v a rs e l f=t h i s ; c l e a r I n t e r v a l ( t h i s . _ w a t c h ) ; v a rt i m e=t h i s . c u r r e n t ( ) ; t h i s . u p d a t e _ c o u n t e r ( t i m e ) ; t h i s . _ s t a r t=t h i s . _ w a t c h=n u l l ; t h i s . $ e l . r e m o v e C l a s s ( ' o e _ w e b _ e x a m p l e _ s t a r t e d ' ) . a d d C l a s s ( ' o e _ w e b _ e x a m p l e _ s t o p p e d ' ) ; v a rr e c o r d={ u s e r _ i d :i n s t a n c e . s e s s i o n . u i d , t i m e :t i m e , } ; t h i s . m o d e l . c a l l ( ' c r e a t e ' ,[ r e c o r d ] ) . d o n e ( f u n c t i o n( ){ s e l f . d i s p l a y _ r e c o r d ( r e c o r d ) ; } ) ; } , d e s t r o y :f u n c t i o n( ){ i f( t h i s . _ w a t c h ){

Note that we're only displaying the record once we know it's been saved from the database (the c r e a t e call has returned without error).

Mic check, is this working?


So far, features have been implemented, code has been worked and tentatively tried. However, there is no guarantee they will keep working as new changes are performed, new features added, The original author (you, dear reader) could keep a notebook with a list of workflows to check, to ensure everything keeps working. And follow the notebook day after day, every time something is changed in the module. That gets repetitive after a while. And computers are good at doing repetitive stuff, as long as you tell them how to do it. So let's add test to the module, so that in the future the computer can take care of ensuring what works today keeps working tomorrow. Note Here we're writing tests after having implemented the widget. This may or may not work, we may need to alter bits and pieces of code to get them in a testable state. An other testing methodology is TDD (Test-Driven Development) where the tests are written first, and the code necessary to make these tests pass is written afterwards. Both methods have their opponents and detractors, advantages and inconvenients. Pick the one you prefer. The first step of Testing in OpenERP Web (../testing/) is to set up the basic testing structure: 1. Creating a javascript file section diff file

static/src/tests/timer.js

2. Containing a test section (and a few tests to make sure the tests are correctly run) section diff file

static/src/tests/timer.js o p e n e r p . t e s t i n g . s e c t i o n ( ' t i m e r ' ,f u n c t i o n( t e s t ){ t e s t ( ' s u c c e s s f u lt e s t ' ,f u n c t i o n( ){ o k ( t r u e ," s h o u l dw o r k " ) ; } ) ; t e s t ( ' u n s u c c e s s f u lt e s t ' ,f u n c t i o n( ){ o k ( f a l s e ," s h o u df a i l " ) ; } ) ; } ) ;

https://doc.openerp.com/trunk/web/module/

10/16

03/12/13

Building an OpenERP Web module

3. Then declaring the test file in the module's manifest section


__openerp__.py ' j s ' :[ ' s t a t i c / s r c / j s / f i r s t _ m o d u l e . j s ' ] , ' c s s ' :[ ' s t a t i c / s r c / c s s / w e b _ e x a m p l e . c s s ' ] , ' q w e b ' :[ ' s t a t i c / s r c / x m l / w e b _ e x a m p l e . x m l ' ] , ' t e s t ' :[ ' s t a t i c / s r c / t e s t s / t i m e r . j s ' ] , }

diff

file

4. And finally after restarting OpenERP navigating to the test runner at / w e b / t e s t s and selecting your soon-to-be-tested module:

the testing result do indeed match the test. The simplest tests to write are for synchronous pure functions. Synchronous means no RPC call or any other such thing (e.g. s e t T i m e o u t), only direct data processing, and pure means no side-effect: the function takes some input, manipulates it and yields an output. In our widget, only f o r m a t _ t i m e fits the bill: it takes a duration (in milliseconds) and returns an h o u r s : m i n u t e s : s e c o n d formatting of it. Let's test it: section diff file

static/src/tests/timer.js

https://doc.openerp.com/trunk/web/module/

11/16

03/12/13

Building an OpenERP Web module

o p e n e r p . t e s t i n g . s e c t i o n ( ' t i m e r ' ,f u n c t i o n( t e s t ){ t e s t ( ' f o r m a t _ t i m e ' ,f u n c t i o n( i n s t a n c e ){ v a rw=n e wi n s t a n c e . w e b _ e x a m p l e . A c t i o n ( ) ; s t r i c t E q u a l ( w . f o r m a t _ t i m e ( 0 ) , ' 0 0 : 0 0 : 0 0 ' ) ; s t r i c t E q u a l ( w . f o r m a t _ t i m e ( 5 4 3 ) , ' 0 0 : 0 0 : 0 0 ' , " s h o u l dr o u n ds u b s e c o n dt i m e sd o w nt oz e r o " ) ; s t r i c t E q u a l ( w . f o r m a t _ t i m e ( 5 3 4 0 ) , ' 0 0 : 0 0 : 0 5 ' , " s h o u l df l o o rs u b s e c o n de x t e n t st ot h ep r e v i o u ss e c o n d " ) ; s t r i c t E q u a l ( w . f o r m a t _ t i m e ( 6 0 0 0 0 ) , ' 0 0 : 0 1 : 0 0 ' ) ; s t r i c t E q u a l ( w . f o r m a t _ t i m e ( 3 6 0 0 0 0 0 ) , ' 0 1 : 0 0 : 0 0 ' ) ; s t r i c t E q u a l ( w . f o r m a t _ t i m e ( 8 6 4 0 0 0 0 0 ) , ' 2 4 : 0 0 : 0 0 ' ) ; s t r i c t E q u a l ( w . f o r m a t _ t i m e ( 6 0 4 8 0 0 0 0 0 ) , ' 1 6 8 : 0 0 : 0 0 ' ) ; s t r i c t E q u a l ( w . f o r m a t _ t i m e ( 2 2 7 3 3 9 5 8 ) , ' 0 6 : 1 8 : 5 3 ' ) ; s t r i c t E q u a l ( w . f o r m a t _ t i m e ( 4 1 6 7 6 6 3 9 ) , ' 1 1 : 3 4 : 3 6 ' ) ; s t r i c t E q u a l ( w . f o r m a t _ t i m e ( 5 7 8 0 2 0 9 4 ) , ' 1 6 : 0 3 : 2 2 ' ) ; s t r i c t E q u a l ( w . f o r m a t _ t i m e ( 7 3 4 5 1 8 2 8 ) , ' 2 0 : 2 4 : 1 1 ' ) ; s t r i c t E q u a l ( w . f o r m a t _ t i m e ( 8 4 0 9 2 3 3 6 ) , ' 2 3 : 2 1 : 3 2 ' ) ; } ) ; } ) ;

This series of simple tests passes with no issue. The next easy-ish test type is to test basic DOM alterations from provided input, such as (for our widget) updating the counter or displaying a record to the records list: while it's not pure (it alters the DOM "in-place") it has well-delimited side-effects and these side-effects come solely from the provided input. Because these methods alter the widget's DOM, the widget needs a DOM. Looking up a widget's lifecycle (../widget/), the widget really only gets its DOM when adding it to the document. However a side-effect of this is to s t a r t ( ) it, which for us means going to query the user's times. We don't have any records to get in our test, and we don't want to test the initialization yet! So let's cheat a bit: we can manually s e t a w i d g e t ' s D O M (../widget/#openerp.web.Widget.setElement), let's create a basic DOM matching what each method expects then call the method: section diff file

static/src/tests/timer.js

https://doc.openerp.com/trunk/web/module/

12/16

03/12/13

Building an OpenERP Web module

w . f o r m a t _ t i m e ( 8 4 0 9 2 3 3 6 ) , ' 2 3 : 2 1 : 3 2 ' ) ; } ) ; t e s t ( ' u p d a t e _ c o u n t e r ' ,f u n c t i o n( i n s t a n c e ,$ f i x t u r e ){ v a rw=n e wi n s t a n c e . w e b _ e x a m p l e . A c t i o n ( ) ; / /$ f i x t u r ei saD O Mt r e ew h o s ec o n t e n tg e t sc l e a n e du pb e f o r e / /e a c ht e s t ,s ow ec a na d dw h a t e v e rw en e e dt oi t $ f i x t u r e . a p p e n d ( ' < d i vc l a s s = " o e _ w e b _ e x a m p l e _ t i m e r " > ' ) ; / /T h e ns e ti to nt h ew i d g e t w . s e t E l e m e n t ( $ f i x t u r e ) ; / /U p d a t et h ec o u n t e rw i t hak n o w nv a l u e w . u p d a t e _ c o u n t e r ( 2 2 7 3 3 9 5 8 ) ; / /A n dc h e c kt h eD O Mm a t c h e s s t r i c t E q u a l ( $ f i x t u r e . t e x t ( ) ,' 0 6 : 1 8 : 5 3 ' ) ; w . u p d a t e _ c o u n t e r ( 7 3 4 5 1 8 2 8 ) s t r i c t E q u a l ( $ f i x t u r e . t e x t ( ) ,' 2 0 : 2 4 : 1 1 ' ) ; } ) ; t e s t ( ' d i s p l a y _ r e c o r d ' ,f u n c t i o n( i n s t a n c e ,$ f i x t u r e ){ v a rw=n e wi n s t a n c e . w e b _ e x a m p l e . A c t i o n ( ) ; $ f i x t u r e . a p p e n d ( ' < o lc l a s s = " o e _ w e b _ e x a m p l e _ s a v e d " > ' ) w . s e t E l e m e n t ( $ f i x t u r e ) ; w . d i s p l a y _ r e c o r d ( { t i m e :4 1 6 7 6 6 3 9 } ) ; w . d i s p l a y _ r e c o r d ( { t i m e :8 4 0 9 2 3 3 6 } ) ; v a r$ l i s=$ f i x t u r e . f i n d ( ' l i ' ) ; s t r i c t E q u a l ( $ l i s . l e n g t h ,2 ," s h o u l dh a v ep r i n t e d2r e c o r d s " ) ; s t r i c t E q u a l ( $ l i s [ 0 ] . t e x t C o n t e n t ,' 1 1 : 3 4 : 3 6 ' ) ; s t r i c t E q u a l ( $ l i s [ 1 ] . t e x t C o n t e n t ,' 2 3 : 2 1 : 3 2 ' ) ; } ) ; } ) ;

The next group of patches (in terms of setup/complexity) is RPC tests: testing components/methods which perform network calls (RPC requests). In our module, s t a r t and w a t c h _ s t o p are in that case: s t a r t fetches the user's recorded times and w a t c h _ s t o p creates a new record with the current watch. By default, tests don't allow RPC requests and will generate an error when trying to perform one:

To allow them, the test case (or the test suite) has to explicitly opt into r p c s u p p o r t (../testing/#TestOptions.rpc) by adding the r p c : ' m o c k ' option to the test case, and providing its own "rpc responses": section diff file

static/src/tests/timer.js

https://doc.openerp.com/trunk/web/module/

13/16

03/12/13

Building an OpenERP Web module

s t r i c t E q u a l ( $ l i s [ 0 ] . t e x t C o n t e n t ,' 1 1 : 3 4 : 3 6 ' ) ; s t r i c t E q u a l ( $ l i s [ 1 ] . t e x t C o n t e n t ,' 2 3 : 2 1 : 3 2 ' ) ; } ) ; t e s t ( ' s t a r t ' ,{ t e m p l a t e s :t r u e ,r p c :' m o c k ' ,a s s e r t s :3 } ,f u n c t i o n( i n s t a n c e ,$ f i x t u r e ,m o c k ){ / /R a t h e ro d d l o o k i n gs h o r t c u tf o rs e a r c h + r e a di nas i n g l eR P Cc a l l m o c k ( ' / w e b / d a t a s e t / s e a r c h _ r e a d ' ,f u n c t i o n( ){ / /i g n o r ep a r a m e t e r s ,j u s tr e t u r nap a i ro fr e c o r d s . r e t u r n{ r e c o r d s :[ { t i m e :2 2 7 3 3 9 5 8 } , { t i m e :8 4 0 9 2 3 3 6 } ] } ; } ) ; v a rw=n e wi n s t a n c e . w e b _ e x a m p l e . A c t i o n ( ) ; r e t u r nw . a p p e n d T o ( $ f i x t u r e ) . t h e n ( f u n c t i o n( ){ v a r$ l i s=$ f i x t u r e . f i n d ( ' l i ' ) ; s t r i c t E q u a l ( $ l i s . l e n g t h ,2 ) ; s t r i c t E q u a l ( $ l i s [ 0 ] . t e x t C o n t e n t ,' 0 6 : 1 8 : 5 3 ' ) ; s t r i c t E q u a l ( $ l i s [ 1 ] . t e x t C o n t e n t ,' 2 3 : 2 1 : 3 2 ' ) ; } ) ; } ) ; } ) ;

Note By defaut, tests cases don't load templates either. We had not needed to perform any template rendering before here, so we must now enable templates loading via t h e c o r r e s p o n d i n g o p t i o n (../testing/#TestOptions.templates). Our final test requires altering the module's code: asynchronous tests use deferred (../async/) to know when a test ends and the other one can start (otherwise test content will execute nonlinearly and the assertions of a test will be executed during the next test or worse), but although w a t c h _ s t o p performs an asynchronous c r e a t e operation it doesn't return a deferred we can synchronize on. We simply need to return its result: section diff file
u s e r _ i d :i n s t a n c e . s e s s i o n . u i d , t i m e :t i m e , } ; r e t u r nt h i s . m o d e l . c a l l ( ' c r e a t e ' ,[ r e c o r d ] ) . d o n e ( f u n c t i o n( ){ s e l f . d i s p l a y _ r e c o r d ( r e c o r d ) ; } ) ; } ,

static/src/js/first_module.js

This makes no difference to the original code, but allows us to write our test: section diff file

static/src/tests/timer.js

https://doc.openerp.com/trunk/web/module/

14/16

03/12/13

Building an OpenERP Web module

s t r i c t E q u a l ( $ l i s [ 1 ] . t e x t C o n t e n t ,' 2 3 : 2 1 : 3 2 ' ) ; } ) ; } ) ; t e s t ( ' w a t c h _ s t o p ' ,{ t e m p l a t e s :t r u e ,r p c :' m o c k ' ,a s s e r t s :3 } ,f u n c t i o n( i n s t a n c e ,$ f i x ,m o c k ){ v a rc r e a t e d=f a l s e ; m o c k ( ' w e b _ e x a m p l e . s t o p w a t c h : c r e a t e ' ,f u n c t i o n( a r g s ,k w a r g s ){ c r e a t e d=t r u e ; / /r e t u r naf a k ei d( u n u s e d ) r e t u r n4 2 ; } ) ; m o c k ( ' / w e b / d a t a s e t / s e a r c h _ r e a d ' ,f u n c t i o n( ){ r e t u r n{ r e c o r d s :[ ] } ; } ) ; v a rw=n e wi n s t a n c e . w e b _ e x a m p l e . A c t i o n ( ) ; r e t u r nw . a p p e n d T o ( $ f i x ) . t h e n ( f u n c t i o n( ){ / /V i r t u a ls t a r tp o i n t5 sb e f o r e' n o w ' w . _ s t a r t=n e wD a t e ( )-5 0 0 0 ; r e t u r nw . w a t c h _ s t o p ( ) ; } ) . d o n e ( f u n c t i o n( ){ o k ( c r e a t e d ," s h o u l dh a v ec a l l e dc r e a t e ( ) " ) ; s t r i c t E q u a l ( $ f i x . f i n d ( ' . o e _ w e b _ e x a m p l e _ t i m e r ' ) . t e x t ( ) , ' 0 0 : 0 0 : 0 5 ' , " s h o u l dh a v eu p d a t e dt h et i m e r " ) ; s t r i c t E q u a l ( $ f i x . f i n d ( ' l i ' ) [ 0 ] . t e x t C o n t e n t , ' 0 0 : 0 0 : 0 5 ' , " s h o u l dh a v ea d d e dt h en e wt i m et ot h el i s t " ) ; } ) ; } ) ; } ) ;
[1]

they are not alternative solutions: they work very well together. Templates are used to build "just DOM", sub-widgets are used to build DOM subsections and delegate part of the behavior (e.g. events handling).

About Us
Events (https://www.openerp.com/events) News (https://www.openerp.com/news) Jobs (https://www.openerp.com/jobs)

Developers
Download (https://www.openerp.com/start? download) Launchpad (https://launchpad.net/openobject) Automated Tests (http://runbot.openerp.com)

Services
Pricing (https://www.openerp.com/pricing)

Documentation
Get Help (http://help.openerp.com)

Documentation (/) Find a Partner (https://www.openerp.com/partners/directory) Paper Books

Become a Partner (http://www.amazon.com/s/ref=nb_sb_noss_1? (https://www.openerp.com/partners) url=searchContact alias%3Dstripbooks&field(https://www.openerp.com/contact) Training keywords=Openerp&rh=n%3A283155%2Ck%3AOpenerp) Report a Bug References (https://www.openerp.com/events#view=training) (https://bugs.launchpad.net/openobjectFree E-Books (https://www.openerp.com/references/directory) Online Training addons) (https://www.openerp.com/ebooks) OpenERP Open Days (https://www.openerp.com/onlineHelp Translate Developer Memento (http://opendays.openerp.com) training) (http://doc.openerp.com/v6.1/contribute/07_improving_translations.html) (http://doc.openerp.com/memento/OpenERP_Technical_M Certification Exam Presentations Twitter (https://www.openerp.com/certification) (http://www.slideshare.net/openobject/presentations) (http://twitter.com/openerp) Education program Facebook (https://www.openerp.com/educational(http://www.facebook.com/OpenERP) program) Google+ (https://plus.google.com/+openerp/posts)

Offices

https://doc.openerp.com/trunk/web/module/

15/16

03/12/13

Building an OpenERP Web module

Europe/Africa
Sales Office Avenue Edmond Van Nieuwenhuyse, 5 (Serenitas building) 1160 Brussels, Belgium

Americas
Sales, Services 260 Main Street, Suite 203 Redwood City, CA 94063, United States

Asia Pacific
Sales office Room 4, 1/F, Kodak House II 321 Java Road North Point, Hong Kong

+32 2 290 34 90 (tel:+32 2 290 34 90)


Services & R&D Chausse de Namur, 40 1367 GrandRosire, Belgium

+1(650)307-6736 (tel:+1(650)3076736)

+852 3115 7709 (ext. 25) (tel:+852 3115 7709)


Services & R&D 16 / 17, IT Tower 1 Infocity Gate - 1 Gandhinagar - 382007, Gujarat India

+32 81 81 37 00 (tel:+32 81 81 37 00) +32 81 73 35 01 (fax) (fax:+32 81 73 35 01)

+91(79)40 500 100 (tel:+91(79)40 500 100)

https://doc.openerp.com/trunk/web/module/

16/16

Vous aimerez peut-être aussi