On 11/08/11 13:01 +0200, Albert Cervera i Areny wrote: > A Dijous, 11 d'agost de 2011 11:59:56, Cédric Krier va escriure: > > On 11/08/11 11:50 +0200, Albert Cervera i Areny wrote: > > Have you a better UI idea? > > Not to cover all cases. For me the approach of adding the functionalities I > added with another module was ok. But doing as you suggest is ok for me too > because we will end up having two modules anyway. > > Of course an easy to use UI would not cover everything that is possible with > python expressions but regarding dates in our case what we would do is > (always > thinking on Spanish market needs): > > - Add a payment_days field in account.invoice.payment_term which can accept > zero, one or more days of the months (that is from 1 to 31). This is > necessary > due to the payment days issue we have in Spain and exposed in another thread. > - Remove current delay field. > - Add a days field. > - Add a months field (months added first and days later).
This doesn't look supporting the full functionnality of dateutil.relativedelta
I think their interface is good and should match every cases.
So of course we could add all the parameters as fields but this will be:
year, month, day, years, months, days, weekday, leapdays, yearday,
nlyearday
I find it makes a lot of fields where just some will be filled and the UI is
less userfriendly.
But with a simple char field with expression like "months=1, day=15", the UI
is simplier.
> With this, we can get similar functionality because end of the month would be
> achieved by setting '31' on account.invoice.payment_term but prevents from
> having two payment terms one on day 5 and the other one at the end of the
> month but have never met the requirement here. Of course, others may have
> different experiences and needs.
You will need to reimplement a relativedelta with less functionnality and
border cases. I think it is better (KISS) to reuse dateutil functionnalities.
> For me the most important think is that the API is clean as it is. Then I see
> two approaches:
>
> - Create a simple interface that does not have everything and extra things
> are
> created using new modules.
> - Create a powerful interface that does almost everything maybe for
> non-newbie
> users and create newbie-ready modules.
I think that with a simple Char field the interface is simple and it has all
the powerful.
> By the way, thinking about the API I'd like to add a new parameter with the
> total amount requested to get_value(). Currently the definition looks like
> this:
>
> def get_value(self, line, amount, currency):
>
> and It'd look like this:
>
> def get_value(self, line, reminder, currency, total_amount):
>
> The total_amount can be interesting for some exotic calculations but mainly
> it
> would allow for the division (or another percent concept) to be calculated
> over the total amount.
Yes for sure the cumulative computation is not easy to understand.
If we change it for a static computation, it should be replaced not appended.
Because we must not mix concepts otherwise it adds complexity for no advantage
as you can the both computation are equivalent.
Indeed the difficulty is to make the migration from one concept to this other
but it is doable if we have a Python expression for the "precentage".
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: [email protected]
Website: http://www.b2ck.com/
pgpQfCPHQ6Sai.pgp
Description: PGP signature
