Merge lp:~openerp/openobject-client/property_attribute into lp:openobject-client

[Husen Daudi]

Branch to add property attribute on chat field like.

<field name="name" property="upper"/>
<field name="name" property="lower"/>
<field name="name" property="numeric"/>

so that widget will accept only upper/lower or numeric values.

To test the feature you need to merge this server branch too:
https://code.launchpad.net/~openerp/openobject-server/property_attribute/+merge/41147

[Olivier Dony (Odoo) (odo-openerp)]

Hello Husen,

Thank you for the merge proposal(s). The implementation looks simple enough, however the upper/lower conversion doesn't look like it could work for non-ascii characters, which makes it a bit useless as OpenERP should be compatible with all kinds of alphabets.

But anyway even if that worked, I'm afraid we can't consider merging this at this point for 6.0, for a few reasons:

- there are no modules really needing this feature in the current official addons, so I think FP will not accept adding small features like this, as it just makes the system more complicated for no real added value (unless you know of a case where this is required in current addons?)

- forcing textfield content to uppercase/lowercase seems like it can be done more reliably at the model level, so that any write() to the model will be supported, not just those coming from a client that support these "properties".

- forcing textfield contents to numeric values looks more like it should be an integer field, as again it would be supported properly at model level

- finally, if we decided to implement this sort of special case at client-side, both clients would need to be modified to support it, and after RC2 it is too late to introduce such features.

Thanks a lot for taking the time to make the merge proposals, though.
I suppose you needed this feature for a customer project, and it perhaps makes sense to keep it for that project, but we cannot include it in the core at the moment.

I will close the proposals for now and perhaps we can re-consider this after release 6.0.

I hope you understand my point of view...

review: Disapprove

[Christophe CHAUVET (christophe-chauvet)]

Hi

That a great feature, for ours cutomers we often inherit create or write to put uppercase or lowercase on their profile, if we can just add property="upper" it really great.

But to convert in upper or lower, please use lower or upper python function on a unicode string [1], and don't substitute ascii code.

for numeric, it's more complexe and i don't think it a good idea to include it

You can add "title" [2] property

Regards,

[1] : http://stackoverflow.com/questions/727507/how-can-i-do-unicode-uppercase
[2] : http://docs.python.org/library/stdtypes.html?highlight=title#str.title

review: Needs Fixing

[Christophe Simonis (OpenERP) (kangol)]

What about just a specific widget?

<field name="foo" widget="char_upper"/>
<field name="bar" widget="char_lower"/>
<field name="baz" widget="char_capitalize"/>

In this case, no need to change the server.

[Christophe CHAUVET (christophe-chauvet)]

Hi Christophe

The code on the server is only one line on a RNG file, it's not very terrific ;)

But add widget it's not a bad idea

One thing is sure, i want this feature :)

Regards,

[Albert Cervera i Areny - http://www.NaN-tic.com (albert-nan)]

I think this should configurable. We've met some customers that would have enjoyed the application automatically convert text to upper case but in all and every field in the system. So I think this should be configurable globally and simply patch the server would be enough. With no need of changing client code.

[Christophe CHAUVET (christophe-chauvet)]

Hi Albert

Yes, i just spoke the possibility to have one, not by default on a official module

it more quickly for us to add one attribute in the XML, instead of add code in "create" or "write" method

Regards,

[xrg (xrg)]

On Saturday 08 January 2011, you wrote:
> Hi Albert
>
> Yes, i just spoke the possibility to have one, not by default on a official
> module
>
> it more quickly for us to add one attribute in the XML, instead of add code
> in "create" or "write" method

I like the idea, in general. That's why I had initially given it a ++ vote.

However, in any features that we decide to officially support (anything we put
in the RNG ) needs to be well thought of and "stay" for long. We cannot add
and then remove or redefine features like that.

So, suggested course:
We define the specification (in a blueprint, a RFC-style text or something), we
share our opinions on it and then we (all) agree to support it. In the feature
submission window of v6.1, we include it, eventually.

[Husen Daudi (husendaudi)]

Few more suggestions,

we can put property="regular_expression" for more generic validation,
property = "upper/lower/numeric"

In base modules for code fields in product/country we can use property="upper", generally code should be in upper case in most of the business packages.

[xrg (xrg)]

On Monday 10 January 2011, you wrote:
> In base modules for code fields in product/country we can use
> property="upper", generally code should be in upper case in most of the
> business packages.

Generally, in a notion that doesn't have to do with the technical side of
accepting the "property" attribute in the RNG...

... I would like to express my /hatred/ against people that use capital
letters all the time in business applications.

Please don't fall into the trap of following these typewriter-era people in
designing a modern ERP application. The mix of small+capital letters conveys
some kind of information (at least) which we don't want to loose.
(example: some applications do convert the emails to uppercase. That's wrong.)

Unmerged revisions

1694. By husen <husen@husen-laptop> on 2010-11-18

added property attribute to make char widget upper/lower/numeric case

=== modified file 'bin/tools/__init__.py'
--- bin/tools/__init__.py	2010-10-12 16:53:15 +0000
+++ bin/tools/__init__.py	2010-11-18 10:17:56 +0000
@@ -25,6 +25,7 @@
 import os
 import time
 from dateutil.relativedelta import relativedelta
+import gtk
 
 import rpc
 
@@ -79,6 +80,22 @@
         attrs['digits'] = eval(attrs['digits'])
     return attrs
 
+def convert_keyval(type, keyval):
+
+    numkeys = [getattr(gtk.keysyms, '_%d' % x) for x in range(0,10)]
+    numkeys += [getattr(gtk.keysyms, 'KP_%d' % x) for x in range(0,10)]
+    
+    if type == "upper" and keyval >= 97 and keyval <= 122:
+        keyval = keyval - 32
+        return keyval
+    elif type == "lower" and keyval >= 65 and keyval <= 90:
+        keyval = keyval + 32
+        return keyval
+    elif type == "numeric" and keyval not in numkeys:
+        return 0
+    else:
+        return keyval
+    
 #FIXME use spaces
 def calc_condition(self,model,con):
     if model and (con[0] in model.mgroup.fields):

=== modified file 'bin/widget/view/form_gtk/char.py'
--- bin/widget/view/form_gtk/char.py	2010-07-16 05:41:32 +0000
+++ bin/widget/view/form_gtk/char.py	2010-11-18 10:17:56 +0000
@@ -24,6 +24,7 @@
 
 import common
 import interface
+import tools
 
 class char(interface.widget_interface):
     def __init__(self, window, parent, model, attrs={}):
@@ -35,6 +36,7 @@
         self.widget.set_visibility(not attrs.get('password', False))
         self.widget.set_width_chars(5)
 
+        self.widget.connect('key_press_event', self.key_press_cb)
         self.widget.connect('populate-popup', self._menu_open)
         self.widget.connect('activate', self.sig_activate)
         self.widget.connect('focus-in-event', lambda x,y: self._focus_in())
@@ -43,7 +45,10 @@
     def set_value(self, model, model_field):
         return model_field.set_client(model, self.widget.get_text() or False)
     
-
+    def key_press_cb(self, entry, event, *arg):
+        type = self.attrs.get('property',False)
+        event.keyval = tools.convert_keyval(type, event.keyval)        
+    
     def display(self, model, model_field):
         if not model_field:
             self.widget.set_text('')

=== modified file 'bin/widget/view/tree_gtk/editabletree.py'
--- bin/widget/view/tree_gtk/editabletree.py	2010-09-20 09:58:27 +0000
+++ bin/widget/view/tree_gtk/editabletree.py	2010-11-18 10:17:56 +0000
@@ -23,6 +23,7 @@
 import parser
 import observator
 from tools.debug import debug
+import tools
 
 class EditableTreeView(gtk.TreeView, observator.Observable):
 
@@ -174,6 +175,11 @@
     def on_keypressed(self, entry, event, cell_value):
         path, column = self.get_cursor()
         store = self.get_model()
+
+        if column._type == 'char' and column.name in self.screen.fields and self.screen.fields[column.name].get('property',False):
+            type = self.screen.fields[column.name].get('property', '')
+            event.keyval = tools.convert_keyval(type, event.keyval)
+             
         model = store.get_value(store.get_iter(path), 0)
         if event.keyval in self.leaving_events:
             shift_pressed = bool(gtk.gdk.SHIFT_MASK & event.state)