Navigation

CSS Transformation

RAIN must handle correctly two fragments included in the same view via the webcomponent protocol that define the same CSS selectors and solve name clash automatically. Also it should permit to the author of the page to associate the specific CSS class with the component in the page.

Functional requirements

  1. Rain should support the inclusion of multiple CSS files from different modules.
  2. Releasing a new version of a module that is used as a resource / components repository via webcomponent by another module should not impact the code stability of the client module.

Assumptions

  1. Rain will decorate each fragment with an html block element (probably div).

Implementation

Below you can see two examples of including css files (with module version or latest version) using webcomponent protocol:

1
2
3
4
5
6
<head>
  <title>Page Title</title>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <link rel="stylesheet" type="text/css" href="webcomponent://core-components;1.0/htdocs/css/application.css" />
  <link rel="stylesheet" type="text/css" href="webcomponent://cp-components;1.0/htdocs/css/application.css" />
</head>

1
2
3
4
5
6
<head>
  <title>Page Title</title>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <link rel="stylesheet" type="text/css" href="webcomponent://core-components/htdocs/css/application.css"/>
  <link rel="stylesheet" type="text/css" href="webcomponent://cp-components/htdocs/css/application.css"/>
</head>

The Rain platform should:

  1. Recompile the CSS files involved in the lesscss.org style and provide to the client module the styles needed in order to properly render the content.
  2. Resolve the case where no particular version of a module is specified and use the latest registered version.
  3. Regarding the permissions, it is safe to say that all the pages should be able to use CSS resources from other (service) modules, and no permission to access the service module is to be required from the end-user.

Details

All identified css classes from the aggregator page will be consolidated within one single file (or accessible url). Each class will be prefixed with a key composed from module identifier and module version. What happens when we have nested fragments? For instance we have the following scenario:

The block element generated by Rain (assumption 1) will automatically contain in the class attribute the key added in css to avoid name clashes. This solves the issue transparently for the developer and is not constraint to a specific number of nested levels.

Questions

What happens when we have nested fragments? For instance we have the following scenario:

  1. Q: What happens when we have nested fragments? For instance we have the following scenario:
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
<!--main view-->
<head>
  <link rel="stylesheet" href="webcomponent://example;1.0/htdocs/css/test.css" />
</head>
<body>Features-proposal-css-transformation
  <fragment1 />

  <fragment1 />

  <fragment1 />
</body>

....

<!--fragment1 view-->
<head>
  <link rel="stylesheet" href="webcomponent://example;1.1/htdocs/css/test2.css" />
</head>

<body>
  <p>Ta na na na na. Css possible class clash?</p>
</body>

A: First let’s mock the content of each css file.

1
2
3
4
5
<!-- test.css -->
.myTestClass {background-color: red;}

<!-- test2.css -->
.myTestClass {background-color: red;}

Rain consolidates both css files into:

1
2
3
4
5
<!-- ..... consolidated-url.css -->
<!-- test.css -->
.example-1.0 .myTestClass {background-color: red;}
<!-- test2.css -->
.example-1.1 .myTestClass {background-color: red;}

The resulting html seen in client browser is:

1
2
3
4
5
6
7
8
9
<!--main view-->
<head>
  <link rel="stylesheet" href="..... consolidated-url.css" />
</head>
<body>
  <div class="example-1.0" id="[unique identifier at dom level generated by RAIN]">
    <p>Ta na na na na. Css possible class clash?</p>
  </div>
</body>

Table Of Contents

Previous topic

Client Runtime Storage

Next topic

Dashboard Component Model

Navigation

Created using Sphinx 1.0.7.