So thought I'd do a quick update of what we've been up to in the past couple of weeks, as things have been pretty busy here at Netsight.

First thing to mention is that whilst we are primarily known for our Plone work, the three largest projects that we are working on at the moment are not based on Plone. Aha! the doomsayers say, Plone is declining etc etc. But in fact the opposite, this is a positive thing... let me explain:

One of the main criticisms of Zope and Plone back when they started was that they were not very 'pythonic' ie. everything in Zope and Plone was done differently in every other python system. Some would say that Zope was so ahead of it's time that there wasn't anything else out there, so it was blazing its own trail.

Zope 2 was a very monolithic system and you basically had to use the entire stack. Not only that but every part of the stack was different to any other stack out there in the world. It was a big learning curve. The 'Z' shaped learning curve. Plone came along and hid a lot of this complexity to the average user, and simple customisation could be done fairly simply. As Plone got bigger, things got more complex, and some really clever stuff to make core developers lives easier made some simple customisations more tricky. This is now being addressed, and for Plone 4 much is being removed, creating a much sleeker system.

However the biggest wins for the likes of companies like Netsight that have to recruit, train and retain developers is that there is much more transferable code and skills between Zope and Plone and the rest of the python world. Since much of Plone nowadays is developed in the much more flexible Zope 3 style using Component Architecture you can transfer between other frameworks like Grok repoze.bfg, vudo... and not just the Zope based ones... but its now much easier to move back and forth with WSGI based frameworks like Werkzeug, Pylons, etc.

This is such a tangible benefit for a business. We have recently hired a new developer to work on one of the projects below, and we are currently looking for yet another developer to join us. What is great, is we can look for just 'python' developers, not specifically 'plone' developers as they don't need to know 'plone' now like they used to in order to be productive in a Plone environment.

To give some examples of this, let me talk about a few really interesting projects Netsight is working on at the moment... none of which directly involve Plone, but which all use skills transferable to and from modern Plone development. A no doubt Plone will be stirred into the mix at some point in both these projects' near future.

The first is a several month support and development contract with a large academic-related business. They employ 1,500 staff and their business is interacting with teachers and students across the globe. They built (using internal people) several Zope based web systems for managing the interactions with these teachers and students. These were built quite a few years ago, and are in need of a bit of a refresh and can do with moving to Zope 3. With the help of another company they have moved most of the code out of the ZODB and onto the filesystem so it can me managed much easier. Our first task is to build an events management system for them. They run events worldwide, and this system will take care of bookings and related tasks.

What makes this project so interesting is that we are able to now develop using Zope 3 style and technologies via Five on a Zope 2 existing system. This is really nice as it gives us a much nicer development model (classes, views, adapters etc) rather than the old style of a bunch of 'Script (Python)' objects. It makes it much easier for us to debug (via pdb) and to benchmark and test. Not only that, but we have a new developer working on the project, who whilst has python experience, has little specific Zope experience. Working in this way he has been able to concentrate on the pythonic aspects and leave the core Zope tasks to the more experienced developer on the project.

The second project is really quite a fun challenge. We are dynamically re-skinning an existing .NET portal site... without touching the original site. We are using a WSGI stack with modules that we are developing based upon xdv to dynamically clean up the (nasty, broken) HTML from the original portal and present a nice clean, reskinned site to the end user. Oh, and as we are gluttons for punishment, we are re-writing the URLs of the site too...

OK, so I'm going to let you into a little secret here... this new blog, for one of the UK's longest established Plone development companies, isn't actually written in Plone. Shock! Horror! How can this be? Well our own website was actually designed and built before Plone even really existed. Before Plone, we did all our development in old-skool Zope 2. I guess it's a testament to our designers that even since the last time we re-designed our website nearly 7 years ago our website still gets a lot of praise for its design.

For several years now we've been saying 'we need to get a blog sorted out', but just never got around to it. We've developed countless blogs for clients, but never had time to do our own. In case you are wondering then why this new blog already has a history of articles, that is because for the past year we've had a mailbox setup at work that we've been emailing blog posts to ready for when we got the blog sorted... which of course was only meant to be temporary... (yeah, right!).

So what is this blog running on then, if it isn't Plone? Its running Zine a python based 'clone' of Wordpress. This was partly an experiment and no doubt will change a few times over the life of this blog. So why Zine then? Well, we have been starting to use a technology called Deliverance that allows you to apply a look and feel (theme) to a website without actually touching the site itself.

This was originally created for Plone to allow designers to create themes for Plone without having to know all the guts of Plone and get their hands dirty with python code and viewlets and the likes. It also allows you to apply the same theme to multiple sites and make them look coherent. The upcoming new plone.org website (which Netsight did the visual design for) is going to be using Deliverance to theme both Plone itself and also Trac, the issue tracking tool that the Plone project uses. In our case we use Deliverance to theme both Zine and our own Zope website.

In fact though, Deliverance doesn't theme our website, but uses our website as the theme. Yes that's right, you can specify a URL for the theme file for deliverance, so this could be a local file, or another site somewhere. So we had great fun playing around with this, theming our blog with various other public sites, Ikea, Disney etc etc. And the fantastic thing about it all was that we needed to touch neither the theme source (ie Disney's site) or the content source (Zine). This meant I could setup Zine nice and quickly without needing to get to grips with its (frankly, weird - a separate rant) way of handling theming and customisation.

For those interested in the technical details I'll be writing a subsequent post with technical details of the setup of our site and blog and how we are combining zope, zine, wsgi, deliverance (xdv) all together as one. I'm also hoping to write a bit about the cool project we are working on using the concepts in Deliverance to theme an existing large legacy portal for an organisation.

Whilst playing around with lxml, I came across a problem with some code in xdv that was causing problems with <script> and <style> tags. The contents of these tags was being escaped, and hence all being broken.

Turns out xdv was using lxml.etree.tostring and should have been using lxml.html.tostring.

The latter does not escape certain HTML tags (and probabaly does other things too). The nice thing I found looking at the lxml.html docs are some really handy methods for dealing with HTML, e.g.:

.iterlinks() which gives an iterator over the document that returns all links:

This yields (element, attribute, link, pos) for every link in the document. attribute may be None if the link is in the text (as will be the case with a <style> tag with @import).

This finds any link in an action, archive, background, cite, classid, codebase, data, href, longdesc, profile, src, usemap, dynsrc, or lowsrc attribute. It also searches style attributes for url(link), and <style> tags for @import and url().

More info can be found on the lxml.html page.