Welcome | Get started | Dive | Contribute | Topics | Reference | Changes | More

Introduction to Front end Renderers

One of Lino’s design goals is to make your applications front end agnostic, i.e. independent of the choice of a front end.

Our plan is that one day local system admins can opt to simply replace lino.modlib.extjs by another front end (e.g. one with a less restrictive license). For example The belref project (lino_book.projects.belref) is a Lino application which runs entirely on lino.modlib.bootstrap3 and without ExtJS. The drawback of that application is that it is just a proof of concept. You cannot change any data because the bootstrap ui is read-only. So the road is prepared, but we did not yet reach our goal, mostly because until now everybody is happy with ExtJS.

An important side-effect of our plan is that Lino has (already now) another “front end” which writes everything as text formatted in reStructuredText syntax. This is interface is heavily used for writing technical specifications that are being automatically tested using doctest.

A front end is a special plugin which has its “renderer” (i.e. renderer attribute not None).

The default front end is specified in lino.core.site.Site.default_ui.

Lino currently has three “Front end Renderers” (not to be confused with e.g. the appy renderer):

Besides these two pluggable renderers Lino has a third one

  • TextRenderer, instantiated in settings.SITE.kernel.text_renderer.

Some methods:

  • ar.show : show the specified resource (a table, a request, a database object, …) using the request’s renderer.

  • lino.core.tablerequest.TableRequest.to_rst() : return that table request as a reStructuredText string.

  • lino.core.tablerequest.TableRequest.table2rst() : shortcut to text_renderer.show_table.

Internal