Saturday, August 26, 2017¶
During the last years I occasionally heard customers (or myself) think
that one day we should add a feature which replaces the fields
phone, email, fax, url of a partner by a panel of “Contact
details” where users can enter as many phone numbers and urls and
email addresses as they want. This is easily feasable by a plugin
which works a bit like
lino_xl.lib.addresses. Hamza will
probably need this as well when he starts synchronizing contacts with
Google. So it was time to do it.
I created #2023, after double-checking that we obviously didn’t yet have a ticket for this. The idea is old, but I never wrote a ticket because I had a big problem: how to call that functionality?
Roman Nofenko formulated the same problem last year on stackexchange:
On a web site I have contact details section. This section can contain phone number, email address, personal site, etc. And I have button to add new item for contact details. What is more correct form for ‘Add …’?
My summary of the answers he received:
Contact details is the closest you can get without becoming really obscure. It is defined in Collins Dictionary as “the information required to contact someone, such as an address or telephone number”.
Contact information or contact info is mentioned as being more frequently used, but I don’t agree that it is a better word for our problem just because the combination occurs more often.
So I guess we are going to call that functionality “Contact details”. Yes, the word “detail” as the second part of an expression is suboptimal in Lino because it clashes with our naming conventions: we are going to have a class named ContactDetail which is a model and not a detail layout.
But which internal name to use?
What about lino_xl.lib.contact_details? too long!
What about lino_xl.lib.cdetails? Mnjah…
What about lino_xl.lib.phones?
lino_xl.lib.phones best. Yes, that name is irritating
because the plugin handles more than phone numbers. But it has a few
advantages: one simple word, easy to memorize, letters “ph” not yet
lino_amici.projects.herman project didn’t make much sence
because it had a legacy_data_path and therefore was not runnable on
other machines than mine. Fixed.
testpaths and python_files¶
[pytest] testpaths = tests/__init__.py python_files = lino_cosi/*
The python_files there was causing pytest to collect also the source
files for test cases, which (1) was useless because all test files are
grouped under tests and (2) caused an error on travis because it tried
to import all these files without having any
For documentation about testpaths and python_files see the pytest docs
An error occured while trying to fetch your .travis.yml file¶
I had this funny error message: https://travis-ci.org/lino-framework/xl/builds/268658271
Optimizations for get_simple_params()¶
I fixed a design flaw: when I define simple parameters on a model,
then Lino until now also expected me to define these parameter fields.
For example the
lino.modlib.users.Authored mixin said:
@classmethod def get_simple_parameters(cls): for p in super(Authored, cls).get_simple_parameters(): yield p yield 'user' # cls.author_field_name) @classmethod def get_parameter_fields(cls, **fields): """Adds the :attr:`user` filter parameter field.""" fld = cls._meta.get_field('user') fields.setdefault( 'user', models.ForeignKey( 'users.User', verbose_name=fld.verbose_name, blank=True, null=True)) return super(Authored, cls).get_parameter_fields(**fields)
get_parameter_fields() method there is a useless
requirement. Lino can do this for me since the parameter field is
just a copy of the database field of the same name.
New feature: When
get_simple_parameters contains names for
which no parameter field is defined, then Lino creates that parameter
field as a copy of the database field of the same name.
I removed quite a few get_parameter_fields methods which were now useless.
Side effect: the
get_simple_parameters no longer returns a set
but a list. Because the order of these items is important,
e.g. because it is used by
lino.modlib.checkdata.Problem : both inherit from
lino.modlib.users.UserAuthored and therefore we dont need to
get_simple_parameters() method in therse cases.
I started to write Introduction to actor parameters.
I changed the
lino.modlib.system.models.YesNo to 12 which should fix a
whole series of suboptimal rendering in parameter panels