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
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"
The default front end is specified in
Lino currently has three "Front end Renderers" (not to be confused with e.g. the appy renderer):
The renderer used by
lino.modlib.bootstrap3is defined in
lino.modlib.bootstrap3.renderer.HtmlRendererand can be accessed via
Besides these two pluggable renderers Lino has a third one
TextRenderer, instantiated in
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