openerp-dev-web team mailing list archive

[Boris Timokhin <qoqenator@xxxxxxxxx>]

You think better way return empty dictionary (GTK-client way) or run eval
without try-except?
In last case - may be need remove try-except from gtk-client too? And start
fix hidden buges in exist modules?


2011/8/3 Xavier Morel <xmo@xxxxxxxxxxx>

>
> On 2011-08-03, at 13:43 , Boris Timokhin wrote:
>
> > Sometimes when we try eval string of context or domain may be raised
> > Exception NameError.
> > In GTK-client that problem resolved easy:
> > try:
> >    eval(string, cnx)
> > except Exceprion, e:
> >    logger.getLogger('....').exception(string)
> >    return {}
> >
> > In a begining I do same in controllers.main (see
> > https://bugs.launchpad.net/openerp-web/+bug/816835,
> > and
> >
> http://bazaar.launchpad.net/~openerp-community/openerp-web/qoqenator_lp816835/revision/705
> > )
> > But I think that not correct: If only one name in big dictionary is wrong
> we
> > return empty dictionary.
> >
> > I write function clean_eval for better work with wrong names in eval:
> >
> http://bazaar.launchpad.net/~openerp-community/openerp-web/qoqenator_cleaneval/revision/706
> >
> > Example:
> >
> > string for eval: '{"lang":"US", "action":some_action_exist_in_ctx,
> > "domain":[("name","like","Correct Name"),
> ("status","=",status_not_defined),
> > ("parent_id","in",[23,45,wrong_name_of_id])], "foo":bar,
> > "some_attr":anoter_bad_name}'
> >
> > context for eval function: {"some_action_exist_in_ctx":"open_window",
> > "bar":"biz"}
> >
> > result: {'lang': 'US', 'action': 'open_window', 'domain': [('name',
> 'like',
> > 'Correct Name'), ('parent_id', 'in', [23, 45])], 'foo': 'biz'}
> >
> > You can see: pair key:value with wrong name removed from dict, wrong name
> > removed from list and domain tuple contains wrong name remove from domain
> > list.
> I don't think that's sensible or logical: we have no way to know if the
> result makes any
> sense or has any coherence if we arbitrarily remove random stuff from it.
>
> Barring client bugs (which are definitely possible), I think having a
> NameError in the
> evaluation of a context or domain means whatever generated it (likely a
> view) is broken. If
> the variable may or may not be in the evaluation context it should use
> context.get.
>
>