I think I'll add it with a warning message to change to the new behavior when the user uses it the old way. Em 26 de fev de 2016 20:20, "Lubomir I. Ivanov" <[email protected]> escreveu:
> On 27 February 2016 at 01:04, Dirk Hohndel <[email protected]> wrote: > > On Sat, Feb 27, 2016 at 12:58:29AM +0200, Lubomir I. Ivanov wrote: > >> On 27 February 2016 at 00:24, Dirk Hohndel <[email protected]> wrote: > >> > Both of the options you offer above sound like they have significany > drawbacks, but I'd really > >> > like to know how this would look from a user's perspective. > >> > >> the refactoring Tomaz did, introduced a minor regression in the > >> Grantlee variable syntax which is exposed to the user. > >> NOTE: the same applies to both weights and cylinders, but i'm going to > >> talk about weights (for the sake of example). > >> > >> latest public release (i think?) has these: > >> - dive.weights used to print all weight details > >> - dive.weight1-N prints a single weight detail > >> > >> master: > >> - dive.weights, should print all weight details again, but it doesn't > >> work for me > >> - dive.weight.1-N (notice the extra dot) > >> > >> the options are simple: fix dive.weights and 1) use the new syntax for > >> 1-N or 2) bring back the old syntax. > >> if we introduce the new syntax it has to be re-documented and it will > >> break at least for the user who originally requested the feature. > >> > >> what is currently is master is much more tidy, code wise and if we > >> bring back the old syntax it will make the code less pretty. > > > > I don't want to break this for the user, so my strong preference would be > > to go with the less pretty code that does what the users may already have > > in their template files. > > > > ok, i understand. > > Tomaz, for the variables not to break i think we need to introduce a > property and a getter method for every Grantlee variable, e.g.: > dive.weight1, dive.weight2...dive.weightN > dive.cylinder1, dive.cylinder2...dive.cylinderN > > lubomir > -- >
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
