Our aim with the new viewbook V3 pages framework was to develop a system that builds on our experience with the current viewbook pages tool, while expanding it’s capabilities with a brand new core setup. In essence this meant we wanted to take all the good out of the current tool, and put that into a new framework that was capable of producing any type of portfolio website we wanted.

When you don’t know exactly what needs to be build, but you have to start somewhere
This latter part was actually pretty important. The thing is that we at viewbook work as a small dedicated team (on average between 6 and 10 people), heavily relying on prototyping, user feedback and, most importantly, our own inspiration to fine tune the new V3 system. This meant we could not develop a custom fit system from start based on a clear and defined set of guidelines (which we did not know yet). But rather we needed a system that could quickly adapt to anything we could think of along the way.

Use things as they are, do not ‘hack’ them
The way we achieved this is by using HTML, CSS and the Web browser (DOM) as much as possible as they are in their purest form, without trying to change or improve them (by hacking around with Javascript). On top of that we designed an XML and XSLT based core framework for page (and module) generation, whereby the configuration for a page is made as abstract as possible. Also the framework needed to be loosely tied to our database environment for easy integration and optimal scalability. In essence this means we can now import any piece of data, ‘capture’ any styling, behaviour or content configuration in a generalized way and generate any type and form of output we want (more on how that works in a later post!).

Developing in this manner might be a somewhat slower approach as supposed to working with a fixed plan and feature set, and it means you might have to wait a bit longer for V3 then you’d like. But it also means we can afford to be really flexible when it comes to implementing new features based on our ideas and your feedback.

Importing plugins, feeds, designs, etcetera
The new system also makes it easy to integrate features especially for developers and designers. For Developers things like easily integrating custom jQuery plugins in your page and using V3 components in custom websites or WordPress (and other blogging environments), plus importing data into a component from any source you want. And for designers the importing and exporting of designs from and to your favorite design applications (Adobe Illustrator, Indesign), making custom design templates manageable by your clients or act as a third party reseller of your designs.

In any case the main focus for V3 will be the components you use to fill and style your portfolio. And each component can be made as exactly as we want them to be. So that will be the part where this flexibility will pay off the most, and where your feedback will be most valuable. But more on that later in our next update!

At Viewbook we are using XSLT (Extensible Stylesheet Language Transformations) to build a new generation of powerful website building tools within the Viewbook framework (more on that later). I have been working with XSLT for about 4 years now, so it came naturally to me to offer it as the preferred approach to get the system working. But using XSLT isn’t exactly a mainstream approach for web development (yet), so why did we choose XSLT for the job?

What does XSLT solve?
Thinking about how we would ideally set up the new range of tools, it quickly came down to one rather fundamental question. How can we easily combine a multitude of configuration and data sources into all the needed output types? And more importantly, how could we keep the overall system agile and scalable?

The configuration method of choice came down to XML (doesn’t it almost always). It’s easy to produce, great for rapid prototyping (just edit a static file) and can be easily generated by any back-end system. XML configuration does however has it downsides when you want to use it to generate the output. It’s pretty verbose and parsing can be a pain and can require a lot of code, and this is exactly where XSLT comes in.

What is XSLT?
So what is XSLT? In short it is a great way to loop through each and every bit of an XML source, and transform that bit into something else on the fly and only if needed. You can use it to generate any type of output from a single XML source: Text, XML, HTML, CSS, Javascript, SVG, a PDF or anything in between. In essence this means with XSLT you can produce any type of content and truly abstract your data and configuration from your output and transforming logic.

What does XSLT look like?
Letís do a concrete example. Suppose you want to render various pieces of HTML into one or more pages, where each bit has the same basic structure but different content and styling. And as a bonus letís keep the database as a flat as possible.

The XML configuration could look something like this:

And with XSLT like this:

You would produce:

Obviously this is a pretty simple example witch could be improved upon, but thatís simply a case of making more specific template matches and adjust your XSLT as needed.

No disadvantages?
XSLT does has it’s downsides of course, like most technologies do. First of all mastering XSLT can be a steep learning curve and requires a different ‘mindset’ to get started. XSLT is a templating language, you loop, match and transform. Whereas other transform languages often use a loaded DOM and ‘paste’ new content in afterwards. The latter generally would be a more familiar approach for most developers.

Secondly XSLT isn’t really known for it’s mathematical prowess, it’s a XML transformation language after all. Although XSLT 2.0 does solve this for a great deal, that version isn’t really widespread yet. External libraries like EXSLT do solve much of the headaches in the mean time though. And finally working with very large XML documents (as in thousands of lines of XML) can pose performance issues if not careful, although I myself never run into this before.

Conclusion
So XSLT is a great way to produce any type of content from your database and really abstracts configuration from output. Besides this XSLT is a platform neutral way of rendering the output. So that means there is always a XSLT processor you can use in the language you’re most familiar with. And of course XSLT is just about transforming XML, nothing more and nothing less. So if you’re working with XML, XSLT is the way to go.