Setting Up Collective.xdv Best Practice

The collective.xdv documentation has a very good description of the best way to setup collective.xdv read it. I won’t go in to the full details as they are well documented but the basic points are:

Setup a Plone product

Use css registry to serve the css, instead of serving through XDV. This gives you the all the advantages of managing CSS through CSS registry (compression etc).

Create your html/css templates.

In our setup I turned off all stylesheets but kupustyles.css, authors.css, kupuplone.css, kupudrawerstyles.css when serving through XDV. I also created a new stylesheet to pull in what we needed from the admin theme. By adding back in on a case-by-case basis you can avoid CSS conflicts with your themes styles. Of course if you’re completely mad you could decide to restyle the admin interface (good luck with that).

Snags

There were a few snags we ran into. Here’s how we fixed them:

no styling with portal_factory

We ran in to an issue with our Plone setup and portal_factory. The transformation stopped working when you added content, leaving you seeing the default plone theme. Very confusing. Apparently it’s fixed in 3.3. but for whatever reason we had to use this monkey patch:

Styling the Search Box

Using Conditionals to Select Templates

Using Plone’s default body classes or defining your own you can specify which template to use based on class name. This is a big win as you no longer have mess around with macros or the main template. For example:

Pulling in Content

You could bring in content piece-by-piece – writing rules for each element. I found this was time consuming and difficult. In the end it made more sense to pull in the all content from each column. If you want to re-work the HTML of a standard portlet it’s better to use inline XSL (more on that in the next article)
<replace content='//*[@id="portal-column-content"]/div/*' theme='//*[@id="content"]' />

Conclusion

From my perspective:

It gives control of the templating to the front-end dev / designer.

It allows working in parallel with Plone devs rather then them waiting for templates to be completed.

Using collective.xdv dramatically sped up the time we had a skinned site we could show to the client.

We cut the time we spent doing donkey work and increased the time we could spend on worthwhile development.

I’ll leave it to the Senior Developer to give the pros from an experienced Plone developer:

No mangling of reference HTML templates as they are implemented in TAL by Plone Devs

improved team workflow as HTML/CSS Designer/Dev can work in parallel with Plone Devs

lighter workload for Plone Devs as there is much less HTML to implement in TAL

reduced need to explicitly remove unwanted elements from TAL templates – they can mostly be ignored by xdv

flexibility in layout between pages – i.e. one-column, two-column, three-column layouts don’t require a mass of macros and modification of main_template to achieve. This can instead be pushed up to the XDV layer.

Jonathan began with an overview of the current mobile landscape. In a nutshell it’s a minefield of platform fragmentation and device fragmentation.

“‘It’s brutal to develop natively across platforms”

Jonathan Stark

So what to do? Well, we then looked at three approaches; native, web and hybrid. All have their advantages but hybrid looked the way to go for most mobile use cases. In Jonathan’s words the advantages are:

Web files bundled in native executable

Access to device APIs

Sell in native app stores

Not perfect, but pretty damn good

Next we looked at some useful guidelines for the mobile use case. A nice summation would be “Do one thing and do it well”.

CSS3

We looked at various CSS3 features; advanced styling, transforms, transitions, animations etc. There’s a wealth of information out there on these so I won’t go into too much detail. Here are some interesting pointers:

android requires text-shadow to have a blur value.

box-shadow has performance issues, particularly on Blackberry (consider using media-query to turn off for Blackberry).

border-image is particularly interesting, as it does away with sliding doors css.

animations are hardware accelerated on iOS.

be careful of z-index on transforms. By default on it stacks above static positioned elements.

box-reflect works with form elements.

box-shadow takes up space like borders.

box-reflect works on <VIDEO> tag.

Talk of hardware acceleration for animation in the next version of Android (Ice Cream Sandwich).

I liked the look of CSS animations. I have some reservations of how manageable they will become on medium to large projects. Having written code based animation sequences in Flash I know from experience it can get pretty complicated managing dependances and interactions. Using LESS, or SASS looks like an absolute must for using CSS animation on anything but the smallest projects.

HTML5

Next up was looking at some of the useful offline features of HTML5. Namely; web storage, web SQL database and application cache. My personal favourite was web storage – it looked easy to use and very useful for state maintenance. Application cache also looked great but I can see huge problems debugging, even Jonathan struggled to demo it properly.

Phonegap, jQTouch and Sencha Touch

Here we looked at the various frameworks for building hybrid apps. Again there is a ton of info out there. Jonathan was obviously keen on jQTouch but I actually think Phonegap looked the more promising platform for development. It seemed to have a good balance between ease of use, learning curve and features. Sencha Touch looked really powerful, whilst jQTouch looked lightweight and quick to build with.

Debugging

In the final part of the day Jonathan showed some great debugging tools. If you’ve ever had to debug mobile CSS you know what a pain it is to debug on the device itself. The stand out star for me was weinre, a really fantastic tool for debugging mobile apps. The basic premise is it gives you access to the webkit inspector on your laptop which in turn is linked to the phone browser. It allows you to see exactly what is happening on the phone and allows live editing as well. Pretty amazing really.

Conclusion

Jonathan’s workshop has re-enforced my opinion that writing mobile apps for all formats is best done using HTML5 / CSS and JS. The key benefits are:

write once*

The skills are already available and less costly than hiring native specific developers

CSS3 brings us a host of new features. Whilst most people will be familiar with gradients, text-shadow etc. I’d like to draw your attention to one of the lesser known modules in CSS3: flexbox. What’s interesting about Flexbox is that you can use it now if you use a Gecko or Webkit based browser (no IE sadly and Opera’s support isn’t there yet).

What does Flexbox bring us that we didn’t have before? Well it gives us a whole raft of new ways of controlling layout and flow. What we now achieve with floats we can do far more successfully and with more control with Flexbox.

I’ve never liked floats, they always seemed a hacky way of structuring HTML. Unfortunately with the meager positional CSS available, floats ended up being the best way of creating flexible fluid layouts. Let’s look at some examples.

display: box

To define an element as a flexbox we set the display to box.
.flexbox {
display: -moz-box;
display: -webkit-box;
display: box;
}

box-ordinal-group

The immediate application of this should be obvious, for the first time we have way of defining display order without reverting to all the hacks we’ve had to use up to now (floats, relative positioning, negative margins etc). Powerful stuff.

Further more you can set relative spacing whilst having fixed width paddings and margins. If you tried that with floats you’d either have to use percentage margins or have boxes bouncing all over the place.

Final Example

The classic 3 column layout. Notice the navigation appearing first, also note that the background colour extends to the full height of all boxes.

Sadly flexbox is not supported by IE and looks unlikely to be supported by IE9. So it will be a while before these techniques become mainstream.

About us: Isotoma is a bespoke software development company based in York and London specialising in web apps, mobile apps and product design. If you’d like to know more you can review our work or get in touch.

Recently I’ve been tasked with looking at how we can improve our Plone theming process.

One of the problems that most teams come across on any web project is how to spend less time doing the basics and more time solving the unique problems that each project throws up. This seems to be especially true when it comes to skinning / implementing user interfaces. No matter what framework / CMS I’ve used (and I’ve used plenty) it’s often hard to square the circle between what we want as output and what is actually produced.

Another aspect that can eat up time is having to implement user interface changes during development. Even with the best sign-off procedures, designs, and by extension HTML templates are often subject to change. With that in mind the key objectives we are looking for in a theming method are:

Write a custom stylesheet. It’s amazing what you can do with CSS, but that alone won’t cut it. We need to able to specify the HTML output to meet our high standards of accessibility and design.

Create a ‘vanilla’ theme product. Creating a Plone theme is not for the faint hearted and to be honest it had me stumped. You really need to have a solid understanding of Plone and Zope to create anything worthwhile and while that is not necessarily a problem it’s certainly not my area of expertise.

I could probably grab some developer time here at Isotoma to help me put together this ‘vanillla’ product, but even that doesn’t answer our needs in the level of flexibility we require. There must be an easier way….

Deliverance / Collective.xdv

The future of Plone theming lies in Deliverance / Collective.xdv and will be at the core of Plone 4 theming (so I’m told). You can start using it now though. (see this excellent tutorial to get started )

It took a little effort to get a working buildout, mainly because I couldn’t get lxml working on my mac (necessary for collective.xdv). So I installed it on an Ubuntu VM which worked just fine.

Once I’d got it working it didn’t take me long to realise the potential of this new way of theming. In a nutshell, it allows you to have whatever output you want. Not only that but it allows template development to happen separately and in tandem with the main development effort.

Let’s have a quick look at how it works. At it’s simplest level you have 2 files: theme.html and rules.xml. The theme.html file is a standard html template and you can write this however you want. It is the rules file where it gets interesting. I won’t go in to the full details (see here for a full description) but here are some examples of what you can do.

Replace content:

this replaces the element in the theme.html with whatever content Plone produces within #content element.

Append / prepend content:

<append content='/html/head/style' theme='/html/head' />

this adds all the styles from Plone.

Discard content:

<drop theme='/html/head/comment()' />

This removes comments form the theme.html appearing in the site.

It uses Xpath, something that I’m familiar with and very easy to learn. With deliverance it gets even easier because you can use CSS 3 selectors. All-in-all you have a very powerful way of theming Plone whilst having a fantastic level of separation and flexibility.

I’m very hopeful that collective.xdv / Deliverance will be the solution we are looking for and I’m really looking forward to using it on forth coming projects.

About us

This is the blog of Isotoma, a software development company based in York and London. We help our customers design, build and run online products, services and marketing tools; from subscription publishing, through Software as a Service and native & hybrid mobile apps to content managed websites — we help our customers every step of the way.