Monday, August 8, 2016

Hippo Site Toolkit Scaffolding

Play framework, ruby on rails, grails and klein have it why hippo not? I'm talking about routing and centralized configuration adhering the design patterns don't repeat yourself and convention over configuration [1]. The main principle of Hippo CMS is the idea of letting the content determin the design and structure of code and website. Usually websites are driven by there menu / page structure, semantic URLs were implemented since people and search engines didn't like query parameters and url rewriting also is part of todays php implementations. Hippo CMS facilitates this principle due to a flexible hostname and url configuration, serving content via distinct urls, channels and websites. Theoretically speaking content can be mounted into any part of the website (facets, mounts), though from my point of view the content is not the main driver of the configuration model. The core of the configuration model are sitemap items like part of route based frameworks. Configuration freedom and flexibility provides with it the burden of maintainance if you create a trade of chart, I assume there is a beak even that at some point complexity becomes expensive, and outweights flexibility so you should always try to minimize complexity even if the model allows you to create complex inheritance structures.

Humans make mistakes and don't like repedetive error prone tasks, so I though I do the attempt to apply play frameworks routing and combine it with a component notation which indicates the basic structure of a website and provides a comprehendable overview of the main idea of the configuration model.

#HST scaffold example

#URL                   CONTENTPATH                          COMPONENTS
/                       /home                                home(header,&main(banner, doc),footer)
/contact                /contact                             &text(header,*main,footer)            
/simple                 /simple                              simple                                
/news/:date/:id         /news/date:String/id:String          news(header,*main,footer)             
/news                   /news                                newsoverview(header,list, footer)     
/text/*path             /text/path:String                    *text                                 
/text/content/*path     /text/content/path:String            *text 
You see the same url content path placeholders as play framework provides, combined with a c - function like notation that let's you create page component structures. From my point of view it is easier to comprehend a text tree view where components are in place instead of mapping a model in your head. The remaining head mapping part are pointers and references where you need to imagine aggregated components and structures, though the jcr model doesn't force you to abstract and reuse structures either. Initially you can create the configuration structure of your project and than scaffold your project by convention, hst-scaffold creates the respective component and tempate structure, pages, sitemap-items, freemarker templates, includes and java files. Where you just fill in the codes. Warning: the current status of the project is still experimental and not supported by Hippo. Additionally when you build a scaffold there is the hidden directory .scaffold created that saves a history of changes for possible rollbacks, default templates for java and freemarker files as well as a configuration file.

The other way around, the attempt of creating a scaffold from an existing project, is a challanging task. There is still work to do, I don't know if I will continue finishing the idea, depending on time and interest. Though basically it would allow you to compare configurations of for example acceptance and production enviroments and see what differences or changes are regardless of the hassle to compare xml files, jcr trees and directories.

If you like to join or reuse the code feel free to charm in, for details have a look at: