On 14/12/09 19:54 +0100, Chenal Bertrand wrote:
> Le 14/12/09 19:32, Hartmut Goebel a écrit :
> >> This representation is of course more verbose (and more difficult to
> >> read for a human) that the current implementation but provides a
> >> solution that is easier to parse for non-python software. This would
> >> allow to interact easily with the Tryton server in any language
> >> (currently any external program need to understand strings like:
> >> "company' in context and '=' or '!=' ", "context.get('company')",
> >> etc).
> >>
> >
> >> On Dec 14, 4:15 pm, Cédric Krier<[email protected]> wrote:
> >>
> > I'm not quite sure what exactly you are proposing. Are you proposing to
> > change the domain specific language as the user/programmer writes it or
> > as it is passed to the client?
> >
> > If you are proposing to change the language as passed to the client, I'
> > with you. We should be language independent here.
> >
> > I vote against changing the language as the user/programmer writes it in
> > such a way as you both propose for some reason: Programmers have to
> > learn yet another language, we gain no benefit here and the current
> > language is easily parsed in python.
> >
> >
> >>> [{'__class__': 'eval', 'v': "['parent', '=', False]"}]
> >>> {'company': {'__class__': 'eval', 'v': "company or False"}}
> >>> {'__class__': 'eval', 'v': "[16, currency_digits]"}
> >>> {'__class__': 'eval', 'v': "len(lines) and True or False"}
> >>>
> > This is terrible unreadable! We should not expose this to the user nor
> > to the programmer. It looks ugly and is redundant.
> >
> > bch schrieb:
> >
> >
> >> Another solution is to use a list representation of those strings
> >> (inspired by Scheme syntax), example here: http://dpaste.org/ZJey/
> >>
> > Maybe we could extend your idea towards some function-oriented style.
> > This should allow a very simple implementation on almost every language
> > suporting some kind of 'evel()'. In Python this could be implemented
> > quite easily like in the example: http://dpaste.org/kIZy/
> >
> > IMHO this a a bit more readable than bch proposal since it tights the
> > arguments towards function.
> >
> >
> Nice improvement. I forgot to say that with my version, because there is
> no need of eval anymore, there is no more risk of code injection (even
> if the current eval usage has been secured).
> If we want to remove the python string for the client. I think it is better to remove it also from the server side. Because indeed those strings are already a issue in some cases see: http://hg.tryton.org/hgwebdir.cgi/modules/project/file/5e2baff83a4b/work.py#l26 I propose to replace it by a syntax composed of python object like this: Tuple(If(In(Eval('company'), Eval('context')), '=', '!='), Eval('id'), Get(Eval('context'), 'company')) The advantages are: - they can be manipulated by Python on the server-side because it is Python Object - we can implemented a json function to dump it on the fly into a json string like: {'__class__': 'Tuple', 'v': {'__class__': 'If', 'v': {...}}} And the client can inteprete it when loading the json. - they are not soo much verbose compare to Python statement - we good implement specific function for common pattern Disavantages are: - we need to check all the strings in XML (domain and context of ir.action.act_window) and Fields (domain and states). But any way, they was not so easy to extend as I showed above. - it will increase a little bit the size of fields_view_get result. -- Cédric Krier B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email: [email protected] Jabber: [email protected] Website: http://www.b2ck.com/ twitter: http://twitter.com/cedrickrier identi.ca: http://identi.ca/cedrickrier
pgpaUugGGPhD6.pgp
Description: PGP signature
