webschuur.com

Drupal is not object oriënted (OO). No really, it is not! It merely borrows some design principles from OO, and uses some design concepts (such as the Observer Pattern, or hooks, in Drupal) from OO. Though many Module developers actually use another design principle, that of Classes. When creating a module, one can borrow almost all ideas from the (good) design of classes, to create a good design for a module.

Maybe you think: “Why should I design my module”?

iDeal is a Dutch, online payment system, widly adopted, but hard to implement.

In Drupal there are several iDeal implementations for übercart, but none are very solid and none are easy to implement. Moreover: the iDeal übercart implementations lack some error handling, which may not matter for smaller sites, but for large payment flows, this is far from ready.

Git Cola provided a very nice dialog explaining me how to improve my commit message:

A good commit message has the following format: - First line: Describe in one sentence what you did. - Second line: Blank - Remaining lines: Describe why this change is good.

I did some additional research and found some good other guidelines. from stack overflow

Nice tip for all the Drupal hackers out there: snipplr code snippets for Drupal. It also has an RSS feed. Obviously, as with any unknown source, one should never ever use these snippets (except when you know PHP well).

Oh, and there is a nice jQuery feed too.

I found a really nice tracking system, dedicated for feature request: FeVote.
Since I’d like to try if it actually works as one would expect, I removed the ability to request features, on Tagadelics issuetracker. openend a project for it on FeVote.

So: if you have requests for tagadelic, log in (openID) or register over there and add your request, or vote for existing ones.

If it works, then I think I will use it for more (Drupal related) projects.

The downside, I guess, is that people will start to expect a certain feature to appear, once it gains enough votes; which, obviously, may not happen. After all: development is not a democratic process.

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.