Monthly Archives: May 2008

XCRI project

XCRI (Exchanging Course Related Information) is a JISC-funded project to get HE institutions to produce course data in a universally exchangeable format, so it can easily be accessed and used by other institutions, end-users, and aggregators. It’s a bit like an RSS feed for courses.

Kent University have a JISC-funded mini-project to produce an XCRI feed, and I’m running the project. I’m adding entries to my personal blog because at the moment we don’t have Kent blogs, so this will have to do for now.

One of the main problems we have at Kent – a problem shared by many other institutions seemingly – is that although we obviously have a reliable and structured source of course data, we don’t have a structured source of public-friendly information. The sort of stuff that goes into a prospectus for potential students. But XCRI is attempting to gather exactly that sort of information: the stuff you want to advertise to the outside world.

This isn’t just a data-mining exercise. Sure, the first practical hurdle is picking out the relevant bits from html and flat text held in our prospectuses and webpages, and putting all this into a structured format such as XML or a relational database. But the bigger problem is changing the way people work. I won’t go into the details of how the publications are generated at the moment, but suffice to say it’s largely paper- and Quark-driven. The webpages have to be manually created after this process, and there’s no source of data other than flat documents.

So the biggest hurdle is going to be setting up a new system where the data comes first, and from this web and print can be generated. This in turn means collaborative, workflowed systems (a CMS?!), pushing out XML. The XML can then be turned into whatever you want.

Well, that’s the theory. I’ll have to see what happens over the next couple of months…

Zaninotto

Looks like Francois Zaninotto, one of the core symfony developers, has quit the team. He was largely responsible for the documentation, and co-authored the excellent symfony book, published by Apress.

One of the key successes behind symfony was the documentation. The fact that there was human-readable documentation, and not just an API, was a remarkable thing for an open source project. It’s surely to the detriment of the project that he’s no longer a part of it.

Hopefully he’ll continue to play an active role in the community, and might even consider writing documentation independently of the core team. We’ll just have to see what direction symfony head off in over the next couple of years.

The Squiz Licence

I’ve recently been looking more closely at MySource Matrix, an open source PHP-based CMS. It’s very important to realise that ‘open source’ is not necessarily what you might think in the real world of running an enterprise CMS.

Squiz

So what about the details of using MySource Matrix in anger? First off, the software is essentially managed by one company, Squiz, based in Australia. It was (as far as I can see) very much developed by them, and while additions and improvements may have been added by people in a user-community over the years, what you get when you download the system is essentially a Squiz product.

Dual licence

Then there’s the dual licence. This basically means that you can download the software, install it on your laptop or server or whatever (as I did) and start playing around with it. This comes under a GPL licence, and you’re free to do whatever you want with it. Squiz have even kindly released hundreds of pages of documentation on how to use the system.

But you’d have to be a brave soul to do this for anything other than your department’s website, etc. Imagine your university or large corporation wanted a CMS, and you offer them something for which you have no training, and only a superficial idea of the mechanisms behind it because you can only spend 50% of your time on it? Would you really want to be to blame for that disaster-in-waiting?

And I think this is exactly what Squiz have realised, and exactly why they have a dual licence. That is, if you want something a bit shinier, more bells and whistles, proper training, proper support… well, really you need their SSV (Squiz Supported Version) licence. This is where things seem to change somewhat. 

The SSV bit

Once you enter SSV territory, you seem to agree that in essence everything you have is owned by Squiz. Moreover, you must tell Squiz about any changes you make to the code, and those changes aren’t yours. They belong to Squiz. This may scare some, and horrify true blue open source devotees. I should point out that it appears that, according to this page, that you can actually opt to limit your obligation to Squiz (for a fee). You can even opt to resell your own changes commercially, although I’d imagine this option demands an even bigger fee.

In any case, I wonder, is it really so terrible not to be able to modify the code, and still retain ownership of those changes? Would you really want to make any changes to a complex and well-supported system? About a year ago I had to tinker with phpBB to make it work in the way we wanted. Great. But now we have a system which would be hard to update if there were any new security patches. I also remember going to a Plone talk once, at which some developers proudly demonstrated how brilliant Plone could be. The only caveat was that it had taken them years of expert development to get to that point, and their version of Plone was so wildly different from the out-the-box version that updates were a significant problem.

It’s free

As far as I’m concerned, Squiz’s dual licence is sort of open source. It isn’t true open source, but really I don’t care. The main thing is that it’s much much cheaper to get hold of than other CMS vendors (ie no up front licence fee of £80k), and you can see all the code and work out what’s going on.

OK, changing that code and retaining ownership of the changes is another thing, but maybe you really need to be looking at your motives for getting a CMS. If it’s to get: a system which works, which users like, is easy to maintain, has good support, and doesn’t cost too much… well then something like this Squiz’s licence and MySource Matrix might seem like a good idea.

But if you want to spend the next few years tinkering and playing and developing your own modules, and at the end of this process you want to claim the changes as your own… well, maybe this licence scheme isn’t for you.

Summary

Squiz have developed what looks like a good CMS. They provide the software for free, but make their money out of support, design, and training. They also develop a number of extra modules, which they sell to non-educational and non-governmental clients.

But just because the software is free, it doesn’t necessarily mean it’s truly open source. Their SSV licence (essential if you want to use the system to its full potential and do serious stuff with it) means Squiz end up owning any changes you might make. I’m no lawyer, but it even seems like any modules you might develop end up being theirs too.

I don’t think this is necessarily a bad thing, at least if you feel it’s unlikely that you’d do a massive amount of development yourself. And it’s important to know that any changes you do make end up being incorporated into the product, so other Matrix users benefit. I also get the impression that many new bits of code are developed by users with collaboration from Squiz. So overall it seems like a collaborative situation where everyone gains from the development of a new requirement: Squiz make more money, and users end up with a better CMS. Is this bad? I don’t think so.

symfony admin generator

The symfony admin generator is one of the best features of the framework. With just a couple of commands and a few changes to a config file, you can have something pretty close to a database access interface. There’s a simple built in security module, and sfGuard is fairly simple to understand if you need a more complex security module.

At first it seems like the admin code is pretty much pre-baked, and there’s not much you can do to change the behaviour of the interface, save change the config files. But one of the most useful things to know about the symfony admin generator is that you can do extra things. It’s not well documented, but sticking this method:

protected function updateModuleNameFromRequest()

in your actions.class.php file allows you to add in extra code each time anything is done in that module (substitute ModuleName for your own module).

For example, if you need to clear the cache each time something is done, put it here. If you need to update a set of data in a one-to-many relationship with a class, put it here.

It seems curious that more is not made of this function in the book and documentation, because it’s so useful.

And don’t forget you can also use the standard executeAction() methods, preExecute(), postExecute(), etc. in your module’s action.class.php file, in exactly the way a frontend action would work. This means you can add in any kind of custom action to the admin section of your application.

symfony redirect vs forward

I’ve found the distinction between redirect() and forward() a little tricky to draw. It always seems to sound obvious until you need to use them. I found a nice article here http://firebird84vn.wordpress.com/category/symfony/. To quote:

The choice between a redirect or a forward is sometimes tricky. To choose the best solution, keep in mind that a forward is internal to the application and transparent to the user. As far as the user is concerned, the displayed URL is the same as the one requested. In contrast, a redirect is a message to the user’s browser, involving a new request from it and a change in the final resulting URL.

If the action is called from a submitted form with method="post", you should always do a redirect. The main advantage is that if the user refreshes the resulting page, the form will not be submitted again; in addition, the back button works as expected by displaying the form and not an alert asking the user if he wants to resubmit a POST request.

OK, so basically a submitted form should be redirected by the action (as opposed to doing a forward). In other situations where you’re calling part of your own application, just use a forward(). Maybe I’ve missed something, but this seems pretty straightforward (pun unintended) after all.

MySource Matrix and Squiz

I’ve been looking recently at an open source enterprise CMS called MySource Matrix. It’s written in PHP5, and unusually for open source CMS actually seems to be able to cope well at enterprise level.

mysource matrix logo

It’s built from the ground up on an asset basis. Everything is an asset: users, content, permissions, workflow. The whole lot. This allows for a great deal of flexibility and power.

Who?

It is not particularly well-known, at least outside Australia – where the core development has taken place. No one I’ve mentioned it to has heard of it before. It has been adopted by a few organizations (mainly local government and universities) in the UK. In Australia is has a wide user-base, having been originally adopted by the Australian government a few years ago.

This means that there is a good amount of independent support and development from a growing community of users. Being open source anyone can look at the code, make their own improvements, etc. However it’s a complicated system, so any tinkering on a full-on live system would be pretty scary.

Squized

That’s where Squiz come in. Basically this Australian-based company developed the system with grants from the government a few years ago, and released it as open source. It’s been evolving under their guidance ever since, and they’ve added in about a dozen (not open source) plugins. The plugins is one of the ways they make their money.

The other is to provide support for the system. Even though it’s open source, few people would be brave enough to take it on and tame it. Apparently they are beginning to encourage other companies to offer some support services, such as website design. But they are understandably pretty protective about being the sole company to offer full support.

It costs a bit

This is where one might reasonably have some concerns about MySource Matrix. It may be free, but the support and setup isn’t. And because no one else (apart from the wider user community) can offer support, you are in some senses just as locked in to this CMS as a traditional licensed CMS. Of course, the difference is that you might be locked in, but at least you haven’t spent £50k or more on a license. Money that would just rub salt in the wound should things start to go wrong.

Not that other open source CMS leave you any less locked in. For example Plone, a hugely popular CMS, is notoriously nightmarish to configure to your needs. Companies offer assistance, and once again you can end up tied into their particular solution or version of the core.

Not all open

Not everything in MySource Matrix is free. The extra modules (which are pretty crucial) are provided by Squiz under an SSV licence. Anything you do with them is their property. Does this matter? Well, I don’t think so. How often would you really want to tinker with the source code of someone else’s plugins. I guess it just encourages you to make your suggestions to them, and let them do the hard work. Of course, you have to pay for this. But you’d probably not want the development hassle anyway.

Summary

As a summary, I’d say the MySource Matrix/Squiz ticket looks promising. It has some obvious concerns, but they don’t seem to be concerns that are unique or particular to this CMS.

symfony and LDAP

I’ve recently been looking at the essential (ie why isn’t it included in the core?) symfony plugin sfGuard. It offers are really nice, simple way of building a simple user, role, and permissions system into your symfony app.

The great thing is that with a little tweaking (documentation not great) you can add a custom LDAP lookup class, which overrides the standard built in user password lookup. Ok, you need to write your own class, or use a 3rd party one. But the basics of LDAP are built into php5, and it’s really not hard to do.

One problem I had was that sfGuard is designed to make it impossible to do an LDAP lookup and an internal check for a superadmin user. The reasons are a little esoteric, and have to do with mixing static and non-static contexts. Basically, the only option is to change one of the sfGuard library classes. Specifically sfGuardPlugin/lib/model/plugin/PluginsfGuardUser.php

Adding in this fixed things:

    if ($callable = sfConfig::get('app_sf_guard_plugin_check_password_callable_both'))
    {
      $result = false;
      $result = $this->checkPasswordByGuard($password);
      if (!$result)
      {
        $result = call_user_func_array($callable, array($this->getUsername(), $password));
      }
      return $result;
    }

which meant I had to use a special ‘check_password_callable_both’ option in the app.yml file. But at least this way it did checkPasswordByGuard() first, and then tried my added in LDAP class second.

Is there another way of doing this? I don’t know. Probably. But this seemed to work for me, and perhaps could be included in the sfGuard plugin by default. I guess I should get in touch with the developers to check…