openerp-expert-framework team mailing list archive

[Zyphos <zyphos@xxxxxxxxx>]

Hi all,

I agree with Raphaël on simplifying the report syntax but this should be
in another thread (this one).


The final user don't have to be bothered with complicated and long
Python code.

OpenERP needs to be what it claims. RAD Framework
I proposed a blueprint about that for column syntax.
https://blueprints.launchpad.net/openobject-server/+spec/make-column-syntax-easier

A way of keeping trace of those feature could be to use blueprint..

What do you think about gather them into a common blueprint called
"Improve user/integrator experience" ?

--
Nicolas De Smet



Raphaël Valyi a écrit :
>
>
> just a remark, the talk we had recently with Sharoon had two points
> essentially. No matter the reporting engine, we think that tweaking a
> bit Python evaluation and the OpenERP ORM, at least in the context of
> a report could dramatically improve the user experience.
> The whole idea behind it is that if a power user could design their
> report themselves without really being a programmer, integration cost
> would drop dramatically.
> Currently, my experience is that you need to have too many programming
> skills for that to be true.
>
> Let's take a concrete example:
>
> This is a real example from order.rml:
> [[ o.partner_shipping_id.state_id and
> o.partner_shipping_id.state_id.name
> <http://o.partner_shipping_id.state_id.name> or '' ]]
> With two changes, we could actually cut this down too just:
> [[ o.partner_shipping_id.state_id.name
> <http://o.partner_shipping_id.state_id.name> ]]  which is user friendly.
>
> 1) You will never want to write "False" report. At least I propose a
> boolean expression evaluated to False is always casted to "" in
> reports by default. If you really want to print "False", then you
> would need to explicitly tell it with something such as [[ not
> my_expression and "False" ]]. No problem to make this a bit more
> harder as this is very unlikely you would want that.
> This change alone allows to change: [[ o.partner_shipping_id.state_id
> and o.partner_shipping_id.state_id.name
> <http://o.partner_shipping_id.state_id.name> or '' ]]
> into: [[ o.partner_shipping_id.state_id and
> o.partner_shipping_id.state_id.name
> <http://o.partner_shipping_id.state_id.name> ]]
>
>
> 2) Expression evaluation could just break silently when trying to
> browse some attribute from None/False
> So instead of useless caution such as: 
> [[ o.partner_shipping_id.state_id and
> o.partner_shipping_id.state_id.name
> <http://o.partner_shipping_id.state_id.name> or '' ]]
> you would rather just write:
> [[ o.partner_shipping_id.state_id.name
> <http://o.partner_shipping_id.state_id.name> or '' ]]
> if o.partner_shipping_id is False, then evaluation of the chain is
> evaluated to False (so casted to "" if we have point 1), end of the
> story, no exception, no hassle.
>
>
> Now, combine 1) and 2) together and you have:
> [[ o.partner_shipping_id.state_id.name
> <http://o.partner_shipping_id.state_id.name> ]]  instead of 
> [[ o.partner_shipping_id.state_id and
> o.partner_shipping_id.state_id.name
> <http://o.partner_shipping_id.state_id.name> or '' ]]
>
>
> Multiply that small win by all the occurrences of awkward Python
> expressions in an average report and you pass from something that
> sucks to something that is very user friendly.
>
> Finally I think the sxw -> RML > pdf engine could be fixed a bit to be
> WYSIWYG enough for most use. Currently it's very impredictible.
> Depending on the level of table nesting you have, your cells will
> suddenly have borders you cannot remove and all sort of such things
> that make it unpractical for non programmer users used not to track
> the worst bugs even by dumb dichotomy when required.
>
>
> Those are my current wish for a better report engine, no matter the
> template technology. I didn't though too much about how to implement
> it concretely. But please before all, what do you think about those
> ideas? Do you think we can have this cleanly for 5.2?
>
> Raphaël Valyi
> http://www.akretion.com
>