Cascading Data Sheets - Removing logic from templates proof of concept

[TomB]

This was @s_molinari’s idea but I’ve ported it to Javascript: https://github.com/Level-2/Tranjsform

The result of this, is that you can take a XML template, a .tss file of processing instructions and render it on either the client or the server without any duplication of effort It’s entirely portable… one set of templates and their rendering logic which isn’t client or server specific.

[s_molinari]

Thanks Tom. Ideas are cheap. It is the hard work of making them a reality that actually counts and should get the credit. So, to you!

My idea was to make it possible to run the same template system either server side or client side. Sort of “isomorphic”. Tom has gotten us one step further to that reality with some great work. Obviously, a “one size fits all” template system, meaning the same templates can be used both server and client side, isn’t really something plausible for a single application. The decision on where to render the HTML must be made first. Still, standardizing the process between the two “sides” could make any web application platform a good bit simpler.

Also, the basic concept of separating the data binding and data display logic from the content is just plain smart. I mean, there was a serious problem with duplication of work, when the design was in the HTML. So, the separation of design from content was needed and CSS was born. It was a great idea to put the design in CSS.

And if you think about it, the content, especially in a dynamic web application, can also be split up into different “concerns” too. I can think of these three: structure, data and behavior.

Structure comes from the meta languages.

Data is the the actual content one sees rendered in the page and I count a good portion of the HTML tag attributes as a form of data too.

And the last concern is the page’s behavior. This is found in the JS peppered throughout the meta language too.

TSSs cover the data binding and tag attributes currently. I also believe TSSs could cover the splitting of behavior from the structure too. This would basically make the TSS the central touch point between the designer and the front and backend devs. Getting the behavior into the TSSs is a much more difficult undertaking for sure. But, maybe it might be a reality someday, maybe.

Scott

[TomB]

@s_molinari

his would basically make the TSS the central touch point between the designer and the front and backend devs.

I think this is exactly where this should head. Solving the problem asked in this thread: Multiple views in MVC-like PHP Frameworks - #4 by s_molinari TSS really allows a much better method of doing this, especially where you have different people working on the front end and back end.

You’d still have two templates, one for the layout and one for the main content but rather than treating them like separate entities, you build the entire page with a tss targetted at layout.xml

contact.tss gets applied to layout.xml

title {content: "Contact Us";}
nav {content: template("main-navigation.xml"); }
.sidebar {content: template("latest-offers.xml"); }
.content {content: template('contact-form.xml'); }

Where this becomes useful, is that using the same .tss, the designer can run the same tss clientside and see how the contact form looks inside the layout.

[Fangio]

I like this approch especially in context of one aspect of the BEM Methodology: a naming convention is used to declare blocks or elements across different technologies like Javascript or CSS. With CDS you now extend this to the backend/PHP.

What a wonderful vision to have one plain html template that can be used both by frontend and backend templating engines. Complete separation between content, structure, styling and behaviour.