webschuur.com

A good practice. A notorious problem when working with Drupal. An impossibility when moulding Joomla! 1.x into your customers wishes: how to override defaults without forking off (within a tight planning and budget).

Every single CMS, Framework or development toolkit, in some way, allows you to start off, with what the makers think you need. And then allows you to change that into your own wishes. I have written before on this subject, and drew a CMS landscape. That landscape draws one thing: the flexibility. How far a tools can be stretched, so to say.

‘Drupal considered dangerous’ has been echoing trough the RSS feeds for the last days. More often then not, the word Ruby has been mentioned. To kill some FUD before it is even spread, I wrote a short intro on what Ruby and Ruby on Rails are, and how they stand newt to Drupal.

But there is more. Sure, Drupal can be considered dangerous, so should Perl, and Java be, and the same can be said about Wordpress, phpBB etceteras.

To state the obvious: For every problem there is a perfect solution. And not the other way around: For every perfect solution there is a problem. What I am saying is: Don’t consider Drupal the perfect solution for each problem. Don’t think That Ruby on Rails equals forty two.

To illustrate that, I put several solutions for your website in a diagram. This diagram is valid for most, but certainly not all website-development-projects; complete websites, not small improvements to existing sites. On the y-axis we see the amount of effort (development Time, development budget) needed to get a website up. On the x-axis we see the amount of flexibility we want to have. Every “solution” has an area in which it can be deployed, this is marked by an ellipse around the logo of the solution.

In many database driven applications (web-apps) you need some sort of user-system. A system to manage log-in facilities and rights management etceteras. A general “mistake” I see all over the place is that a user equals a person, in these systems. I decided to make a decent normalised concept for this and document it for once :).

The idea is that there are two separate entities: a user and a person. You may, or may not couple them, either now, or later. The benefit is that, using this concept, you have a choice:

This is a morphological overview, to display all te options for deploying a Drupal (and/ or Joomla!! or any other CMS) hosting system.

The way one should read it

In the first vertical column all “tasks” we need to perform are listed, chopped up into the smallest possible unit. Then next to each of these we render all possible tools and solutions for each task, without taking in consideration how ill-suited these tools may be, nor how well they can, or will co-operate. By refusing to look at possible solutions yet, we can make sure that we actually list all options.

Yesterday David pointed me at a cool screen-cast of the Civicspace (CS) installer. His question was, how much Sympal scripts and its install system could use from and be used by the CS installer. Because I got this kind of questions more often, here is a summary and a small status report.

Here is what I need and what I have resources for:

• Sympal is all command-line based. Consultants and developers have command-line skills. (or else they should get another Job :)) )

More a note to myself, but this could be interesting for others to look at too.

In Ruby on Rails there is this very powerfull localization plugin. It uses a very simple concept of .t. For those new to the concept of OOP and Ruby more specific, anything is an object. So “today” a variable containing todays date, is an object too. As is the number 23.4599, or the string “Drupal”. Any object can have a method. “Drupal”.length calls the method lenght for “Drupal”, it will return 6.

.t is a method to anything localisable.
todays_date.t will return a localised version of today.