In piston a portal page is stored as xml file. Rendering a portal page in piston is three phase process –
Phase 1 – Create a tree of tag classes from page xml file
Phase 2 – Processing to minimize page markup
Phase 3 – Write page markup to response
Phase 2 was introduced as I felt that piston was creating duplicate markup in many cases which was not required. For example, if you put multiple instances of a plugin or two or more plugins from an app on a portal page and if the views generated by these plugins are referring to one or more static resources (js, css) from app then it will result in duplicate markup.
Lets assume a plugin is generating this markup –
<div> <script src="js/demo.js"></script> </div>
If there are two instances of this plugin on a page, then final markup will look like as following –
<div> <script src="js/demo.js"></script> </div> <div> <script src="js/demo.js"></script> </div>
As you can see that the markup for loading js/demo.js is repeated two times. You can imagine the duplication in case there are 10 or 20 instances of this plugin on a page which means this markup will be repeated same number of times.
To avoid this problem, a new tag <plugin:head> has been introduced.for app view files. This tag is equivalent of html <head> for app view files. Basically the content of this tag is merged with html <head> tag of a piston frame during phase 2. Since a static resource in an app can be uniquely identified, a reference to a static resource (js, css) will not be written to html <head> tag of a piston frame if it has been written already. This achieves the target of avoiding duplicate markup and sending minimal markup to browser required for proper functioning of a portal page and tiles placed on this page.
Ultra lightweight Java based micro portal technology with advanced (Grid designer etc) features not found in any other portal technology 