A Dijous, 11 d'agost de 2011 14:23:34, Cédric Krier va escriure: > 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
Ugh! I was wrong here. As I explained elsewhere we will add it to party.party (in another module, of course). > > 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. Well I think it's obvious that you'll never the same functionality and that adding all those fields would make no sense. But in the end that's the compromise one must face when creating a UI. If one considers creating a friendly UI instead of a char field expression will always think in user requirements and what are the chances a user needing a "years", "weekday", or "yearday", etc. There are many options probably no user will ever use. So years and months is probably enough. Another good thing to do in these cases is look at what other applications do. The applications I've seen let you introduce months, days and the payment days I mentioned in party.party (apart from the holidays mess that we have in Spain). > > 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. Another problem with this in Spain is making some users write some words in English. That wouldn't be very welcomed for some of them. Yet if you prefer we go for the dateutil expression I have no problem creating a module with a simplified interface for those users. > > 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". Alright. If you agree on that will do it this way. -- Albert Cervera i Areny http://www.NaN-tic.com Tel: +34 93 553 18 03 http://twitter.com/albertnan http://www.nan-tic.com/blog -- [email protected] mailing list
