← Back to team overview

openerp-community team mailing list archive

Re: Draft Proposal for a new field type for OpenERP/Odoo

 


This is not only for products, its for any object. Product was just an example.
Sent from Samsung Galaxy Note

-------- Original message --------
From: Leonardo Pistone <leonardo.pistone@xxxxxxxxxxxxxx> 
Date: 15/07/2014  08:09  (GMT+01:00) 
To: Alaney Kilson Dória <alaney.doria@xxxxxxxxxxxxxxx> 
Cc: openerp-community@xxxxxxxxxxxxxxxxxxx 
Subject: Re: [Openerp-community] Draft Proposal for a new field type for OpenERP/Odoo 
 
Hi,

let me expand a bit with what Guewen said (I agree with him).

Configurable attributes and related issues got much attention, one reason being that they are important for e-commerce applications (see OCA project https://github.com/oca/product-attribute ;)

My advice is, before going any further with new work, give a thorough test starting with module product_custom_attributes on 7.0. 

In particular, you can decide to store attributes as normal columns or to serialize all of them as JSON. Furthermore, you can define different attribute sets for each product (i.e. the product shoe has attributes size and color, where the product computer has attributes disk and ram).


On Tue, Jul 15, 2014 at 8:49 AM, Alaney Kilson Dória <alaney.doria@xxxxxxxxxxxxxxx> wrote:
Hi All,

I'm sending an  updated version with more info added, based on what we discussed here.

Best regards

 	
Alaney Dória
CEO
em.alaney.doria@xxxxxxxxxxxxxxx
tm.+244 925 999 331 | +244 913 728 600
  

Rua Doutor Agostinho Neto, 156, Bairro Azul, Luanda - Angola, Tel: +244 913 728 600 | +244 913 728 650,
Website: www.alien-group.com, Email: geral@xxxxxxxxxxxxxxx

 Não imprima este email caso não seja estritamente necessário. A Terra agradece-lhe!

On 07/14/2014 01:58 PM, Info SHS-AV wrote:
+1
Hope some other guy will express its opinion.

Antonio Maria Vigliotti


Il 14/07/2014 14:52, Alaney Kilson Dória ha scritto:

 	
Alaney Dória
CEO
em.alaney.doria@xxxxxxxxxxxxxxx
tm.+244 925 999 331 | +244 913 728 600
  

Rua Doutor Agostinho Neto, 156, Bairro Azul, Luanda - Angola, Tel: +244 913 728 600 | +244 913 728 650,
Website: www.alien-group.com, Email: geral@xxxxxxxxxxxxxxx
 Não imprima este email caso não seja estritamente necessário. A Terra agradece-lhe!
On 07/14/2014 12:50 PM, Info SHS-AV wrote:
Il 14/07/2014 13:31, Alaney Kilson Dória ha scritto:
Yes that's it.
 
This field is stored by orm in xml schema the user doesn't have any control the way the data is store. This field is just added to the structure to allow the user put their own field. The user field are restricted, and this is the thing I want different opinions regarding what and how would be. For example, should we define a data as "integer", "float", "currency", or just "number". Because user might not know what is the difference.

what we should try to see, is what
May be intersting but we need to limit this feature in order to avoid end user mismatch.
Totally agree.  This is what I'm looking for, to improve the paper.
I think may be dangerous use no text data type, expecially python code like eval tag of xml file; I think we do limit node nesting level and, yes, I agree data cannot be related field. Perhaps we could use only text type.
For my point of view, whatever is there will be treated as text. From the point of view of the user  he only see a table on which e can add a field name and it's value. Also the fields are not allow to be used for any kind of operation like add, subs.
Did you think how these data can be used in report?
Good point! that's something to add to the proposal.  Since it's actually a pair (field name, value), assuming that for each         tuple, one can have  no metadata, one can have N. We would make this field be only available for loops (repeatIn). The it would be  just for the sake of more control we could do the following where to put the field name and its value:

object.xml_field_name.fieldName: would print all the existing         field names,
object.xml_field_name.fieldValue: would print all the existing         field values,

This would allow to control where and how I want to put this data. This would not allow indexing, since for each tuple we         don't know it's max size. so if there is data it will print all, inside a loop.

Imagine having spec for a car in database, which car is your product with its specs, and at the same time having also a car part with it's own spec.

Also to remember that for form view, the client will not necessarily know field as a name "field  name". It can be like " Property" or "Característic".  I would be adding those ins a widget just as a table, so the user will never write the xml. only the

Furthermore, this field should be searchable


--
Antonio M. Vigliotti
(Presidente & Chief Technical Officer)

SHS-AV s.r.l. (impresa innovativa)
zeroincombenze®

Via Domodossola, 64 - 10145 TORINO - ITALY

Tel. (+39) 011.0566929(2)

www.shs-av.com

PEC shs-av@xxxxxxxxxxxx




_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



Follow ups