Michiel . van Vlaardingen

If you develop a lot of projects and are a bit like us, you will recognize this: the reusability dream.  It starts of with a little itch that you are not taking advantage of the knowledge and work in the previous project.  You start with some simple database handling and utility functions and all is fine. For a while…

The next stage is actually creating reusable functionality….   The reason is that you know it will haunt you do the same thing in multiple projects  using copy/paste  as it will need to be fixed some time.

This is also the point where your library turns into a framework: Everything needs to be done in a particular way to fit in your nice reusable scheme of things.  Your project no longer just uses a few nice functions,  it completely depends on it.

As I’ve written before the reason I like plain PHP is what I call the notion of proportional time.  The time you spend is proportional to the complexity of the feature you are building.

The problem with frameworks is that they have smart things built in. The framework makes it easy to do stuff that usually takes much more time. However, it’s almost never smart enough. At this time your framework has evolved so much that every time you will have to pick your poison: either go through a painful adaptation to your framework OR recreate it without your framework and go through the painful tinkering an bugfixing that’s all built into the framework… how frustrating.

In our case this stage expresses itself in SLOW development.  Every small step forward becomes way more complex than the actual feature that you need to built.  It’s completely against the principle of proportional time.  You are locked in your own Framework.

Now is the time that you need to consider whether or not: worse before better applies or that it’s just going downhill.    Two years ago we had a framework where the latter was clearly the case and we just had to drop it.   The problem with it was that it was really an all-or-nothing approach.  In our new framework we can easily take just a step back and use only part of the framework until we have clear ideas about the next level.   We still experience the  locked-in situation from time to time, but it’s much easier to get past it.

Our path to Framework enlightenment has the following steps:

• No collisions: make sure that the library/framework does not collide with other code, this will mean that you can drop it into an existing project without the need to rewrite it first
• Layers: create layers of tools, functions and abstractions. If one layer is to restrictive, you can at least use all tools from the other layers below it
• the framework needs to be out of the way:  You must always be able to do things outside the framework and still access it’s data.
• Everything needs configuration and even more important: defaults
• Override everything: be able to replace small parts of functionality without the need to recreate it completely.
• Constants do not exist:   at some point you will want to be able to manipulate it with code
• Move everything to the framework: if you want to reuse it, don’t create it inside your project directory
• Have a (documented) process (including best practices) to create new things for and using the framework.

We are not there yet, but are confident that this time that the benefits outweigh the extra effort.

We recently decided to choose Python over PHP for a new project. I did not know Python, so I’m currently learning it.  I was always in love with the C like syntax of Java, PHP, etc. and could not really imagine someone liking anything else. However, I have turned around now.  I really, really like Python’s whitespace sensitive approach. It makes all your code look so clean and compact.

It is clear from the start that Python really forces you to take one approach. That seems inflexible at first, but ultimately it gives you less to make a decision about and improves consistency of the code.

I do think there is a lack of documentation at some point. The core language and most important modules have excelent documentation, but that is not true for everything, so sometimes I really felt the need to look at the source.  Which fortunately is very very easy to read.

What really helps me to learn Python as fast as I can is the commandline interpreter, which allows me to simply check what works and how data looks. Furthermore, the PyDev environment is a really great help, with immediate feedback about syntax errors.

If you did not give Python a try yet, please do, even if it looks a bit weird at first, it is really nice to work with.

The use of JavaScript has evolved over the years.  In the early days we would address a form element using:  myform.elementname .      Nowadays we prefer to use myform.elements['elementname'].   A related problem I ran into and only solved yesterday was, why    myform.submit();  was not working. Google presents the answer as the first result: www.thescripts.com/forum/thread542837.html for the query form.submit does not work.

Because my button was named “submit”    myform.submit refers to the button instead of the function.

Today I encountered a similar but harder problem.    Imagine this form:

<form id=”f1″ action=”go.php” onsubmit=”return ajaxSubmit(this);”><input type=”hidden” name=”action” value=”something” /> ….</form>

So I use  document.getElementById(”f1″).getAttribute(”action”);   to get the action and submit using AJAX.   Which works perfectly well in Firefox… and not in IE…

Apparently  IE does not really get you the action attribute but simply  object.action…. which in turn is the input element instead of the action attribute, similar to the first problem.  Unfortunately I can’t come up with a way to fix the script, so I had to replace the HTML all over the place.  (removing the action named input element by defining the action as action=”do.php?action=something”).