openerp-expert-framework team mailing list archive

[Gustavo Adrian Marino <gamarino@xxxxxxxxx>]

Olivier:
Let me add some comments:

   - There is a missing case: the on_change input and output situation.
   On on_change input (like for example if you want to summarize totals for
   the item lines in an invoice), currently you receive the full list of
   commands stored on web client. as parameter of the onchange. Nevertheless,
   if you like, as part of your onchange method, to change the items list, you
   are now limited to IDs lists. I guess that the same serialization rules
   should apply in this case.
   - It does not make sense to use delete commands for newly created
   records (as you suggest in your comments). Delete commands should be used
   only for existing DB records, and thus the rules of processing them are not
   going to set any challenge (as far as I see, the only grey point in your
   statement).
   - In v6.1, serialization only considers changed values, so in the lists
   for 1 command, only modified fields are included (nice to say if we use
   this post as the "Official documentation" (certainly, there is no easy way
   to get a doc for this topic)
   - I guess that the original bug report is not intended to discuss the
   serialization of on2many fields, but to the fact that v6.1 ignores context
   parameters on one2many (no context is passed), and thus you can not pass
   parameters from the 'one side' to the object creation on the 'many side'.
   Nevertheless, I celebrate to have this topic explained in your comment!
   - As far as I understood from your comments, I see no conflicting points
   (out of the delete command commented before). Long to explain, yes, but no
   other alternative

Best regards


2012/6/1 Olivier Dony <odo@xxxxxxxxxxx>

> On 06/01/2012 09:01 AM, Thibaut DIRLIK wrote:
> > In 6.0 and GTK, I used to have things like this in my views :
> >
> > <field name="my_one2many_ids" context="{'existing_one2meny_entries' :
> > my_one2many_ids}"/>
> >
> > This is useful if you want to define some defaults for a new element
> which
> > depends on existings one.
> > However, with the new web client, this context can't eval properly, I
> got a
> > "my_one2many_field_ids is not defined".
>
> It's explicitly prevented in the 6.1 web client, to avoid a gray area of
> unreliable behavior. One2many fields cannot always be serialized reliably
> inside themselves, so it is prevented and you can only refer to their
> values
> from outside, IIRC.
>
> Relying on this "hack" was perhaps not a good idea in GTK either, as the
> result
> may be surprising in many situations - it was certainly never specified nor
> documented as a feature.
> Let's say the o2m initially contained 2 values: [32,34], what do you think
> will
> be the "evaluated value" in context after you have deleted ID 32, added
> one new
> line, and are now modifying the ID 34 one?
> - [32,34]
> - [(0,0,{...}),(2,32),(4,34)] (w/o the current edit)
> - [(0,0,{...}),(2,32),(1,34,{...})]  (with a partial form of current edit)
> - [(0,0,{..}),(1,34,{..})] (w/o the deletion, as it's technically not a
> value)
> Is your code prepared to deal with all these cases?
>
>
> Now it's perhaps a good opportunity to come up with a more formal spec for
> the
> future, if there is any interest...
>
> How do you guys think o2m serialization should work in the various cases?
>
> 0) When returned by read() (server-side)
> 1) When returned as a _defaults value for a o2m field? (addons side)
> 2) When sent to create()? (client side)
> 3) When sent to write()? (client side)
> 4) When evaluated (client-side), e.g for on_change parameters or attrs?
> 5) Any other cases?
>
>
> As a starting point:
>
> 0) read() will always return real values with IDs, so keeping the current
> format [ID1,ID2,...] sounds like the KISS option, with `False` indicating
> no value.
> In fact if we decided that the LINK(4) command is the default o2m command,
> [32,34] could simple be a simplified version of [(4,32),(4,34)], so we'd be
> using consistent formats in the various contexts.
>
> 1) default_get() result is supposed to be similar to read(), so you'd be
> tempted to say: exactly the same as for 0). Except you also need to return
> default values that don't exist yet, and have no ID -> need to mix existing
> values with new ones. As a result, we could say:
> -> must always be a list of o2m commands LINK(4) or CREATE(0), and if
> LINK(4)
> is the default, read()-like results would be supported too.
> Should the RESET-LINK(6) command be accepted here too?
>
> 2) create() should only ever LINK(4) or CREATE(0) values, but other
> commands
> are supported now, which I suppose is fine. If LINK(4) is the default, we'd
> have to support bare IDs too in the command list.
>
> 3) write() is meant to support the full range of commands (1-6), and
> should be
> adapted to support bare IDs too if LINK(4) becomes a default.
> Now, should the order of the commands matter? There are cases where it
> does,
> become the ORM will respect the order when performing the operations, so a
> CREATE(0) fail with a unique constraint violation simply because the
> DELETE(2)
> that follows should have been executed before. Or perhaps the ORM should
> always
> reorder the operations before performing them: [2,3,5,0,1,4,6]?
>
> 4) For consistency we could say that the format for this case is the same
> as
> the one for 1), as the intent is the same:"What are the current lines,
> including possibly unsaved ones?"
> This means deletions will not be returned, so if you need to know what was
> deleted you'll have to diff against the current saved value.
> What about partial changes and evaluating the o2m value while you're
> modifying
> it (i.e. inside it)? If you are editing a o2m child record but haven't
> finished
> yet, should the serialized value include some partial changes? Obviously it
> cannot work 100%, so perhaps it should only include changes up to the last
> time
> you started editing a line... but we can't really tell that, can we? (think
> editable lists etc.)
>
> 5) ?
>
>
> As you see, this is not a trivial topic ;-)
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-framework
> Post to     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework
> More help   : https://help.launchpad.net/ListHelp
>



-- 

Gustavo Adrian Marino

Mobile: +54 911 5498 2515

Email: gamarino@xxxxxxxxx

Skype: gustavo.adrian.marino