So I took Roland's comment and tried to get it integrated into my code. For the tab management it worked well, but for portlet management it was a lot harder. Actually I only have a partial implementation finished. What's missing is the necessary logic to be able to move a portlet in the same tab from one column to another (there are 3 columns a portlet can be in for each tab). The thing that was most important to me was cleaning up the pruning operation. This took some trickery (aka hackery). I think its a better implementation but it does make me a bit nervous. Of course its all still very MySQL only.

The following is more or less just a thought stream dump from my train ride back from frisbee practice. I just wanted to jump start a discussion on how emPHPower should be organized. I think the general idea of establishing a communication hub for core developers, end users and companies has been received with sufficient enthusiasm to start working on some of the boring details. The next logical step seems to be to start to fleshing out how the organization behind this communication hub should be structured. I want to leave as much power as possible with the individual members, which is one of the main reasons why I do not want companies to be come members. When planning all of this I also need to differentiate the "bootstrapping process" and my vision for how things should be afterwards. Actually I will focus on the bootstrapping process, since I think for the most part the members should have the opportunity to decide on the structure later on.

So everybody and their dog hopefully knows about SQL injection attacks these days. Most people should have also heard someone telling them that using prepared statements is the magic super fix to all of these issues. People slightly more in the know will have read that prepared statements lead to all sorts of issues. Some of which can be fixed with hacks (or eventually at the source). Some of which can only be solved of the source also exist of course. Some others can only be fixed with certain assumptions (like using the first set of data for generating the query plan), which might break the original use of prepared statements.

So yesterday I spend a few hours writing out an RFC for ifsetor() (note that I put it into the "declined" section). While working through the discussion again, I realized that I had forgotten an important detail in the discussion: Currently we cannot provide a true COALESCE() implementation, which allows for any number of parameters. As such I totally forgot why people felt that the pass by reference hack was considered by these people as a viable approach. I also finally documented in detail why the addition of the shorthand ternary operator "?:" in PHP 5.3 is no replacement either.

On my current project my team had to develop a portlet interface. Users can load portlets and organize them in multiple tabs with 3 columns per tab. They can reorganize the order of their tabs and move portlets within a tab an also move them to new tabs. Portlets are always placed at the top left when they get added or moved to a tab. Furthermore portlets and tabs can be removed, though the last delete operation can always be undone. All of this essentially required me to devise a plan for how to manage ordered lists inside an RDBMS.