[disclaimer: I previously worked at IPS, forever and a day ago. I also own a company that indirectly competes with their services]

IPS has been releasing some details of IPB 3.0, which will be the latest and greatest release to Invision Power Board. There are two pieces of the new development that I want to touch on, those being the new template engine in this post, and the PHP5 framework transition in the next.

As per the past two major IPB revisions, and even some of the point releases, IPS are notorious for breaking backwards compatibility with modules, components and designs. 3.0 will be no different, with a major rewrite of the kernel and source layer, and a whole new markup for doing templates.

The good news is that the template changes are finally consolidating the various template bits that make up a view into one template. If you want to edit the forum index, you just have to edit one file, not twenty. Same for the other major views in the system.

The problems start when you take a look at the proposed template tags. For sake of comparison, I’ll take the IPB3 template tags and match them against the sGen template tags used in our products.

From a casual observer, it would appear that IPS is falling into the same trap that PHP itself has made a home in: mixed case, mixed syntax.

For instance, if you want to compare two strings in PHP, you execute the following function ( in the global namespace, but that’s another rant ):

$end_result = strcmp( $string1, $string2 );

Let’s say, instead of comparing, now you want to replace one with the other. Logic says, execute strreplace(), right? Haha, no no poor programmer. The PHP gods decided to throw an underscore in for the hell of it, so actually you would execute:

$end_result = str_replace( $string1, $string2, $source );

With that in mind, let’s look back at the IPB3 template tags. The tags do serve a great purpose, but the changes in syntax, style and argument passing is a bit.. confusing?

With IPB3, if you want to parse a date into a format, you do the following:

{%date=”now”|format=”long”|relative=”false”%}
{%date=”1210012321″|format=”manual{d m Y}”%}
{%date=”-1 day”|format=”long”%}

Good format, good layout, pipes break the arguments. To parse a URL, you follow the same format:

{%url=”foo=1&bar=2″|label=”Click Me”|base=”public”|id=”myLink”|class=”linkCSS”|onclick=”this.function()”%}
{%url=”foo=1&bar=2″|base=”public”%}

Then things get a bit WTF. The variable tags:

<variable key=”tdColor” default=”blue” />
<variable key=”tdColor” oncondition=”$foo == “green”" value=”green” />
<variable key=”tdColor” oncondition=”$foo == “black”" value=”black” />

<span style=’color:<variable=”tdColor” />’>Hello World!</span>

And the parse tag:

<parse expression=”sprintf( “14″, “There are %s apples in the bag” )” />
<parse expression=”substr( $data['name'], 0, 10 )” />

o_O

Why not, <parse url= and <parse variable=, along with <parse date=? Switching between the syntax styles is going to cause a huge headache for designers. On top of that, the tag library is extensible, so says IPS. With that being the case, the <parse expression needs to be blacklisted asap. There is absolutely no reason or need to have over what is essentially eval() in sheep’s clothing to a user. Especially a user that can create a custom theme, set it up for download, and have all sorts of SQL/curl() fun. Obviously there will be security checks, but it’s still opening a can of worms. If the user needs to execute PHP in a template, they obviously understand PHP and can write a custom tag for the backend.

In comparison, doing the same functions above are possible with the sGen engine by using the HTML tags shown below:

Global namespace variables ( not inside a dataset ):

<sgen vars=”variableName” />

sGen configuration values ( css path, macro path, etc ):

<sgen config=”configTitle” />

Including other template pieces:

<sgen bits=”templateName” />

Adding data to a template ( example: a topics loop ):

<sgen data=”Topics”>
Name: and <sgen:topicDescript />
</sgen>

The above example is a bit more complicated in that the data member is essentially looping through an array called Topics. To access the data elements in Topics, you use the <sgen:member /> syntax.

There are a short list of whitelisted functions you can call from the templates. The syntax is identical to OOP Jscript, which most designers are probably already familiar with:

<sgen.parse url=”some_url” />
<sgen.parse date=”the date” format=”the format” />
<sgen.parse money=”number” format=”USD” />

Right now we just have the sgen.parse example, but a few others will be added to the spec before final.

Next article I’ll pull some examples of the new PHP5 framework that IPB3 will be using and making some general comments.

NOTE: The Portal picture that has ‘you_fail’ under it isn’t supposed to imply that IPS failed, that’s just the name of the picture, which I chose at random for this article.