openerp-expert-framework team mailing list archive

[Sharoon Thomas <sharoonthomas@xxxxxxxxxxxx>]

Hi all,

This is a very good proposal and we had proposed this as a blueprint to the
report-openoffice team as well.
This is not just in the case of reporting but also in the case of general
coding & modules like poweremail, smtpclient etc.

The generic issue IMHO is the open erp browse object/class which has two
problems:

   1. raises an error when the expression is wrong eg.
user.partner_id.name(if partner id doesnt exist or is false it returns
err so we are forced to
   write user.partner_id and user.partner_id.name)
   2. if a field is empty it return False, it should be possible to
   selectively change what should be the return value if database/computed
   value is null. So if we can selectively opt to choose like
   self.pool.get('model').browse(cr,uid,ids,context={'null_value' = ''}) and if
   browse object respects this, there should be no problem.

In the case of relatorio (open Office reports) I understand that its a field
by fields computation. This makes it go for an easy workaround which would
be to wrap in a try:..except:..else..

For other engines like mako/cheetah/django which generate the whole report
at once, any wrong expression would mean an empty report.

2009/12/8 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
> >
>
>
> _______________________________________________
> 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
>



-- 
Sharoon Thomas
Business Analyst & ERP Consultant
http://bit.ly/5FAJKU