Feature: template design for application

gdolle commented 6 years ago

The key idea of this issue is to separate the portal design from the blueprint and let MADF developers provide one or several web interfaces adapted to the type of end-user. For example, we can have a generic application for computational fluid dynamics, but used by Engineers, Doctors, Student, ... We don't want to show exactly the same information on the portal ( inputs, outputs, images, 3D view etc..).

Possible solution

MADF developers provide aside to their blueprint a design template file that describe what is presented in the portal page. (For example using https://shopify.github.io/liquid/, but not mandatory).

Fake example (detailed)

I give here an imaginary example

Blueprint file

# Inputs that will be available on the portal
inputs:
    simple1:
        description: "simple1"
        default: "mydefaultinput1"
        design_template: "template_A"
        type: string

    simple2:
        description: "simple2"
        design_template: "template_A"
        default: {}

    simple3:
        description: "simple3"
        design_template: "template_B"
        default: {}

# ...

Description

Assume one have some liquid template keywords to display the 3d view, 2d customized view1, 2d customized view2, and monitoring. I will call these liquid keywords portal.3dview, portal.2dview1, portal.2dview2, portal.monitoring. "Liquid system" will translate these keyword to their HTML equivalent. For example, the tosca.3dview can be translated into

<div>
      <!-- the canva contain for example the paraviewweb 3D view -->
      <canvas id="glCanvas" width="640" height="480"></canvas>
</div>

<div>
      <!-- An image is used for the  2D view -->
      <img src="path/to/simulation_result.jpg" alt="CFD 2d view">
</div>

Consider the previous blueprint. The orchestrator plugin automatically define from the new keyword design_template the liquid keyword using the value: tosca.template_A and tosca.template_B. Then these template keywords will be translated by the liquid language into HTML as a list of form (like in the current portal)

<!-- Design Template A -->
<div>
 <form>Simple1:<br><input type="Simple1" name="Simple1"><br></form> 
 <form>Simple2:<br><input type="Simple2" name="Simple2"><br></form> 
</div>

<!-- Design Template B -->
<div>
 <form>Simple3:<br><input type="Simple3" name="Simple3"><br></form> 
</div>

Design template files

Now that one have defined the templates keywords in liquid language, the MADF developer will add two design aside from his blueprint. These design can be chosen on the portal (A default one is provided):

Design 1

Welcome Student John Doe!

Configure your application:
{{ tosca.template_B }}

Visualization:
{{ portal.2dview1 }}

The generated html to import (in iframe or another way) in the portal tool configuration page

<html>
<head></head>
<body>
<p>Welcome Student John Doe!</p><br/>
<br/>
<p>Configure your application:</p><br/>
<!-- Design Template B -->
<div>
 <form>Simple3:<br><input type="Simple3" name="Simple3"><br></form> 
</div>
<br/>
<p>Visualization:</p><br>
<div>
      <!-- An image is used for the  2D view -->
      <img src="path/to/simulation_result.jpg" alt="CFD 2d view">
</div>
</body>
</html>

An example of expected render

mso4sc_design1

Design 2

Design

Welcome Engineer John Doe!

Configure your application:
{{ tosca.template_A }}

Visualization:
{{ portal.3dview }}

The generated html to import (in iframe or another way) in the portal tool configuration page

<html>
<head></head>
<body>
<p>Welcome Engineer John Doe!</p><br/>
<br/>
<p>Configure your application:</p><br/>
<!-- Design Template A -->
<div>
 <form>Simple1:<br><input type="Simple1" name="Simple1"><br></form> 
 <form>Simple2:<br><input type="Simple2" name="Simple2"><br></form> 
</div>
<br/>
<p>Visualization:</p><br>
<div>
      <!-- the canva contain for example the paraviewweb 3D view -->
      <canvas id="glCanvas" width="640" height="480"></canvas>
</div>
</body>
</html>

An example of render

mso4sc_design2

Conclusion

At the end the MADF developer maintain only one application for several web interfaces. The files to be uploaded within the blueprint archive would be

# blueprint.tar.gz
blueprint.yaml
design1.liquid
design2.liquid

Remark1

We could also attach a css (eventually) to let people design the layout positioning, but it is not mandatory.

Remark2

Screenshot show what we would expect as a all-steps/one-click interface. The visualization part can be replaced by the monitoring using tabs/button. For example using the Liquid tag and adding clickable button.

<a src='#'>visualization</a>
<a src='#'>monitoring</a>
{% if visualization %}
  Visualization {{ portal.3dview }}!
{% endif %}
{% if monitoring %}
  Monitoring {{ portal.monitoring }}!
{% endif %}

Then we can expand the idea to other requirements.

gdolle commented 6 years ago

@emepetres @victorsndvg This is the kind of thing @prudhomm was mentioning during the review. Feedback, comments, other idea are welcome.

victorsndvg commented 6 years ago

Hi, one question about this approach.

What security implications have to allow users to upload (and execute) custom code?

If some of them can be exploited, Is there a way to isolate the execution of the templatized code?

gdolle commented 6 years ago

@victorsndvg The goal of liquid is to have customizable page and avoid exploits. https://github.com/Shopify/liquid

Why you should use Liquid

* You want to allow your users to edit the appearance of your application but don't want them to run insecure code on your server.
* You want to render templates directly from the database.
* You like smarty (PHP) style template engines.
* You need a template engine which does HTML just as well as emails.
* You don't like the markup of your current templating engine.

By design it's isolated (depend of course what you do with it).

victorsndvg commented 6 years ago

It sounds great! :+1:

sorry for this basic questions, but I'm not experienced with this kind of things ... :smiley:

gdolle commented 6 years ago

Yes don't worry, it's good to ask question to clarify things for everyone. I think it would be a great step forward in terms of usability if we can provide something like this since we could adapt GUIs per applications :)

gdolle commented 6 years ago

@emepetres I forget to add in the description. But since you're using django for the website, Jinja http://jinja.pocoo.org/ could be used instead of liquid.

MSO4SC / MSOPortal