Thanks to the contribution of Carlos Saltos and Borja Vazquez our JavaScript Template Engine PURE is now working with the JavaScript Framework Prototype

The code is not in the master repository yet, but you can get it in the branch of PURE created by Carlos.

They are also working on the MooTools support.

With the announcement of the DOMAssistant support a few weeks ago, and jQuery initially, it is now three JavaScript libraries that are supported.

Stay tuned

We started the development of PURE with the clear goal of developing a cross-library JavaScript template engine.

Since we are using jQuery as our main JS library in the development of our BeeLit solution, it was obvious to start with this one.

Today, we are happy to announce that PURE has moved another step closer to our initial goal as it now also works with DOMAssistant.

I must say, we haven’t really played a big role here. Everything started with a simple message on the DOMAssistant discussion group

Lim Cheng Hong (one of the three developers behind the library) took the challenge in his hands and made the 6 examples of our Getting Started page working with DOMAssistant in just two days.

You can discover those 6 examples with the DOMAssistant library here

So thank you Lim Cheng Hong and thanks to the DOMAssistant team.

We will soon update our wiki and the PURE website with those new examples.

The next steps will be to port PURE on Prototype, MooTools and Dojo.

If you are ready to get your hands dirty with those adaptations, your help will be more than welcome.

Stay tuned

Thanks to your comments and the requests made on our discussion group we have been able to bring PURE to its next step.

This release contains a few corrections but also a lot of new features:

• Auto-rendering: a new PURE method takes your HTML and your JSON data and merges them automatically. The class attribute is used to map the HTML and the data. (Read more about autoRender and its jQuery version on our Wiki).

• Recursive Template Call

• Functions as directive are called by reference and not serialized

• Attach events to your HTML (Read more)

• Change the id of the template root node (as any other attribute)

• Better string value handling

• Use of named properties in iteration “obj.prop” as well as “obj['name']“

We also made some changes to the PURE environment:

• The Home page and the Getting Started page have been re-done, including more examples

• The source code moved from Google Code to GitHub

• You can find now a technical documentation on the GitHub Wiki

• You can report bugs on Lighthouse

• There is a dedicated jQuery Plugin project

• You can discuss about PURE in French on our French discussion group

We are also actively looking for help in order to port PURE to other JS libraries such as DomAssistant, Dojo, Mootools, Prototype, YUI, …

If you are ready to get your hands dirty, just pass by the discussion group and leave us a message.

Stay tuned

We built PURE with the idea of having the rendering of the HTML on the client.

The idea behind it is to decentralize the power needed to run the application to the clients and also to lower the bandwidth needed (by sending just small pieces of JSON).

If this is good in our context (creation of a business application), some people might have good reasons to render the HTML on the server side.

For example, if you need to have the content of your application or website indexed by Google (for SEO).

We have planned to bring the logic of PURE to our Erlang back-end for our own needs (like sending tables to Excel for example) and there is nothing that should stop anybody from doing the same with any other back-end language.

But there is also the possibility to run the JavaScript on the server side.

While we have received comments about Spidermonkey or Rhino, we have never performed tests until now.

We have however received a message from Davey Waterson, JavaScript Architect from Aptana, telling us that:

PURE works unchanged out of the box with Jaxer running as serverside JS

Have a look at his example. You can also check out the Aptana website for more information about Jaxer

Davey will soon publish new examples of integration between PURE and Jaxer on the Aptana Forum

We’ll keep you updated.

On a more personal note, PURE has been entirely built on Aptana Studio and it was a great surprise to read that the same company was paying attention to our project.

Stay tuned

A few weeks back now, we started the development of our new web application BeeLit.

Of course we had to make several important choices for our IT architecture.

We started by choosing a light, flexible and really fast back-end as mentioned in our post: Why Erlang ?

For the front-end, we wanted the browser to be the center for rendering and aggregating services. (Read our post about True Aggregation, the Browser as a Platform).

To achieve this goal, we had to decide for:

1. a JavaScript library to ease the cross-browser issues and advanced DOM functionality
2. a communication language between the browser and the back-end: JSON ? XML ?
3. a template engine to render the back-end services in HTML

We chose jQuery as our JS library (the reasons of this choice will be detailed in a future post).

We decided to go for JSON as the preferred communication language between the browser and Erlang.

The main reason being:

JSON is JavaScript, and JavaScript is THE language of the browser that runs the client logic.

When an AJAX kind of call returns a JSON, your JavaScript code understands it natively.

When an XML is returned, in some ways, you have to convert it fully or partially to JavaScript variables. Then the data becomes useful in your browser. This remains true even if you use XSLT for the rendering.

Don’t get me wrong. It doesn’t mean that we are closing the door on XML and that we won’t aggregate XML services from other API’s in our solutions. It took almost 10 years for the IT Industry to replace ASCII files with XML. And nowadays, you can find plenty of API’s working with XML. So XML is here to stay.

But receiving JSON data in a browser simplifies the developer’s life dramatically.
(Read the rest of the article…)

For years, every time I would use Regex, Regexp, Regular Expressions (you name it), I would find myself crawling through the enormous library available on RegExLib.com, hoping to find that someone had posted the exact expression I needed.

Then I decided to invest some time in demystifying the beast. I read dozens of websites.

Here’s a series of links that helped me get started:

• Plenty of sites offer tutorials, but this was the first website to show me the light. Granted, the web design is particular. But the content is gold.
• JavaScriptKit presents a simple and clear JavaScript use of regular expressions.
• While learning, I did some testing with the Firebug console, but quickly needed a real testing tool. Lots of free online tester tools are available, you can find them by googling: regexp testing online. The one I prefer and currently use is from gskinner.com. I use the Adobe AIR based desktop version (it was my first AIR app download and I was pretty impressed by the smooth and neat installation).
• Once you are in the comfort zone, Regex cheat sheet is there to remind you the basics

Just a couple of hours of efforts were enough to get started and… a couple of days more of practice to get comfortable.

I hope this will help you. Don’t hesitate to add your own findings in the comments below.