Talk:Public Survey Views

Extendable template

I ( Tammo (talk) )would strongly encourage a structure as there exits in Drupal 7 (by default, without additional settings in configuration files): [I do not know Drupal 8 yet, this uses Twig. I remember that Twig was also mentioned in the LimeSurvey community, but this seems very silent now]

• base views are either in core (all of them at a clearly defined place) or in the base template under views (preferred by me, because then all theme files are together.
• each template may either start from scratch (you then have to write all views) or rely on the core templates, with the possibility to override them
• a template can also be a sub-template of a sub-template.

So for example:

• in the default distribution there is the default template (in XLM file: Base=default)
• in the default distribution there are also two sub-templates of the default template, this is indicated in the template xml file (Base=default)
• a user can define his own template, so he has to write all views himself
• another user may define a new template based (called "my-template") on the default (in xml file: Base=default) and may also define three color variants (called "red", "green" and "blue"), each based on my-template by referring to that template in the xml file: Base=my-template

http://themery.com/dgd7/theming/templates/override Remember: in Drupal a template is what a view is in LimeSurvey

====

Isn't this what we basically already have in place? Olle (talk) 10:44, 18 August 2016 (CEST)

====

Basically this is more: currently you can only override a view (after configuring this in the config.php). What I propose goes further:

• when you choose "default" as the base theme and build your own "custom" theme on top of that, all files in the "default" theme are used and after that all files in the "custom" theme are used. So you can just override js, css, templates and so on. Therefore I would propose to put the whole views structure in that default theme and let other themes either make use of that or override it, while still using the js, css atc.
• I propose to make this multi-layered: based on "custom", you can make "custom-red" which uses the "custom" theme (that is based on the "default" theme) but (for example) only makes the background of the question red.

I realise that we will need to provide something for views that result from plugins. Drupal uses hooks and preprocess functions for that, but I am not knowledgeable enough in coding to explain that. I guess that you will grasp this concept.

Example from my Drupal adventures: I base all my work on the Drupal basic Bootstrap theme. I therefore have created a "TFR Cleanboot" theme, that has functionally all things that I need for my websites. "TFR Cleanboot" is based on the Drupal basic Bootstrap theme. All my customer themes I build based on "TFR Cleanboot". There is of course a performance issue: layering this all makes the CSS files bigger, but it is much easier for people to make their own themes. And I think that more than 90% of the surveys are for small audiences, where performace is not an issue. People that need speed, will have to use the default template or build one from scratch...

Making a completely new theme would be: either

• clone the default and change everything that you want
• start from scratch (I wish you good luck, since we (more or less) ended up doing that, but it is a lot of work)

Tammo (talk)

Answer from --DenisChenu (talk) 11:37, 22 August 2016 (CEST) : I really think it's a great idea , BUT we need some cacahe management for this : all HTML produced part must be cached except for EM part. When user go to the survey : LS don't have to search where is this HTML/tpl part, or this other HTML/tpl part. Find it always on runtime/tplname/.../answers.html (or tpl, not important). Cacahe management of template is done on admin part only ( for example redo whole runtime/tplname/ directory with template editor, or a button somewhere). But in fact : it's n,ot the actual purpose, maybe in 2.6. The actual purpose is only "do the best HTML in core". Update this HTML can be done after in another pull request.

Tammo (talk) OK, caching is beyond my capacities. I'll leave this for now. Let's focus on the other questions: how to make a good basic template as a basis to work on for spin offs. Peter Emil will contribute starting next Wednesday.

--DenisChenu (talk) 12:02, 22 August 2016 (CEST) : adding https://manual.limesurvey.org/Public_Survey_Views#Extendable_template

PeterEmil's vision

Working on our template for LimeSurvey 2.50 gave some serious issues which we like to address. As a designer / fronted developer my religion is to work as clean as possible. When the core or the base of a program is clean and without overrides it is a joy to work with and easy extendable. There is no need to put styling in HTML or depend on JS to create a basic style.

Clean HTML has to be the main focus. I’m helping Denis Chenu to get this ironed out as good as possible. Next to clean HTML there has to be an unbiased clean CSS. This is where proper use of Bootstrap really shines. My vision for this structure is as follows:

Start with: Clean HTML & base template, no JS overrides

The base template only uses plain vanilla Bootstrap. It doesn’t do anything extra with css; it’s use is a correct canvas to check core functionalities. There is no need to override DOM-elements. The views have clean HTML without style-based classes. This way, together with the base template, every user/developer can work on functionalities or extras knowing that the base is correct.

This core-template or base-template can be in core and - when this is possible - even not selectable from the backend; it is the master for all other templates. It’s use is for developers mainly, not the end-user. Actually it is a "mother" of templates.

Follow with: Styling from bootswatch, awesome-checkboxes, sliders and what-not.

These give flavour to a template. The current so-called “default” template is just one of the stylistic approaches. In a stylistic template several css-files can be included in config.xml. When there is no extra (above bootstrap.min.css) css defined, the template will look like the base template.

View-overrides are on my wishlist, but when we can secure what is stated above it will be a joy again creating strong templates for this amazing open-source tool.

PS by Tammo: I hired Peter Emil because he is a strong front end designer and developer. He is the one that created the major part of our TFR Responsive template, which unfortunately now only works for LS 2.06.