20130804 (Sunday, 04 August 2013)¶
Application code becomes easier. Instead of writing:
insert_layout = dd.FormLayout("""
event_type:25 type:25
subject
project company
""",window_size=(50,'auto'))
You can now write:
insert_layout = """
event_type:25 type:25
subject
project company
"""
Because insert_layout are now always initiated with that window_size when specified as a string.
I need to add application-specific rules for selecting the
type of a welfare.notes.Note
in Lino Welfare.
To prepare this, I used the new app inheritance feature
and added a new module lino_welfare.modlib.notes
which extends lino.modlib.notes
.
This was the first time that I extended a detail_layout, and it caused some subtle problems.
First I had to understand we must modify the original
lino.modlib.notes.models.Notes
class object by reassigning
it’s detail_layout and insert_layout attributes.
Subclassing the Notes class might look more clear
coding style:
class Notes(Notes):
detail_layout = NoteDetail()
insert_layout = """
event_type:25 type:25
subject
project company
"""
But that would fail because the original module also defines subclasses of Notes, and we want also all subclasses to use our new detail_layout or insert_layout.
The above trick still works only with the lates version because one thing was to replace:
dl = getattr(cls,'detail_layout',None)
by:
dl = cls.__dict__.get('detail_layout',None)
in lino.core.actors.Actor.class_init()
.
But that wasn’t enough. The above change revealed another problem.
Actors without their own detail_layout will use the layout defined on their parent. But if this parent is overridden in another app, then they must install themselves as the datasource for this detail_layout.
E.g. the Persons table is defined in
lino.modlib.contacts
and overridden in
lino_welfare.modlib.contacts
.
The welfare version does not override
the insert_layout.