20131227 (Friday, 27 December 2013)

More on “App-loading reloaded”

After discovering Aymeric’s implementation for solving the verbose_name of apps, I continue to think about what I think about it…

I perceive it as a symptom therapy which leaves intact the “root of the evil”. But that’s the personal feeling of a revolutionary like me who lives in his own world and does not have any historic Django site to maintain.

My djangosite approach is more powerful… but also more revolutionary. Especially I don’t see how we could avoid to define the installed apps by overriding the get_installed_plugins of a Site class. And we know how conservative Django is.

So basically everything is okay, I don’t hope to convert Django to do what Lino does. I just suggest to differentiate between “app” and “application”. We can continue to call them “apps”, but should refrain from expanding that word to “application”. Because apps are not applications, they are plugins which we happen to call “app” for historical reasons. This rule shouldn’t offend even the most conservative Django developer.

More on djangosite

I updated the djangosite documentation in the hope that other developers understand what i mean.

get_installed_plugins is now allowed to yield items which are generators. This makes aplication code more intuitive. Until today you had to write:

def get_installed_plugins(self):
    for a in super(Site, self).get_installed_plugins():
        yield a
    yield 'django.contrib.contenttypes'
    ...

Now you can write:

def get_installed_plugins(self):
    yield super(Site, self).get_installed_plugins()
    yield 'django.contrib.contenttypes'
    ...

Side effects:

• New attributes app_name and app_module for each Plugin.

• Apps that do not define a “Plugin” name will now nevertheless receive a Plugin instance that represents them using default values.

I removed the Site.add_site_attribute method and replaced it’s only usage (in lino.modlib.accounts) by a Plugin attribute.