Tag Archives: dojo

Some tests for P4A 4.0

In the last few weeks I’ve been thinking a lot about the future of P4A, there would be a lot of small things to do but I wanted to think about something big enough for a major release jump.

Some time ago we discussed about the rendering layer, at the moment we generate all the HTML and we use our custom CSS + some jQuery/jQuery UI goodness to enhance everithing a little bit. Point is that jQuery UI is growing too slowly and we need something bigger and more RIA oriented, like Dojo, ExtJS or Qooxdoo. We discussed about which one would be better and at the moment I’d go with Dojo, it has a great FLOSS license, it’s supported by a lot of major players, it’s highly modular and it has my preferred way of including modules. At last I cannot avoid talking about the new wonderful “Claro” graphical theme, simply amazing.

So I started coding some of P4A’s widgets just to test something out and everything was pretty easy, I’d choose to use the declarative syntax because it was the fastest way to have everything running but now I’m running into a few major problems.

First of all I faced a performance issue, maybe it’s due to dojo’s declarative syntax I chose and I should definetively do a comparison test with the programmatic syntax (also if I do not like generating javascript too much). Another problem is due to the fact that most P4A developers tend to use the easiest P4A’s AJAX stack, which actually redraws all the mask (the body tag) without a full page refresh. To do the dojo has to redraw all the widgets in the mask and so the performance issue is not only visible during the first page loading but on every page redrawing. The user would see the page flicker (if we decide to hide the DOM while dojo is rendering) or the unstyled elements for a sec and than the styled widgets. This is not the best way to go…

But here we’ve the most critical issue, every time the page is redesigned (not using a full page refresh) we’ve a noticable memory leak, dojo keeps allocating memory and this is very very bad. That’s not a dojo problem, I mean, I replease the DOM nodes and recall the dojo parser, but the previously built dojo objects are not removed from memory. Actually I hoped that dojo would have recognized that an element was already parsed but this is not happening. Thus we would have to destroy all dojo objects before redrawing them but this operation will make the page flickering longer.

Conclusions? Hard to tell at the moment. I think I want to try a different way doing a quick test using only dojo’s CSS instead of the whole javascripts also because in a P4A application all the events have to be managen by the server and not by the client. I’ll try to do this kind of test ASAP and let you know some more considerations about this topic.

P4A 3 rendering layer discussion

This post will not be easy to write… I’ll try to explain you what kept us really busy in the past 2 weeks. ok a screenshot could help me :-)

In the P4A 3 roadmap post, I told you about a new widget rendering system… I didn’t post more technical info intentionally, I wanted to create a bit of suspense :) but I also wanted to do some tests before publishing news.

For P4A 3 we’d like to have a killer graphic with killer features (resizable widgets, border layouts, beautiful and powerful menu and so on) thus we looked to the biggest javascript frameworks out there: extjs and dojo. Both have great features and both have issues.

Extjs as really a killer graphic layout, and it’s released under LGPL3 (developers wrote some licensing notes that I can’t really understand… actually I think that those notes could conflict with LGPL3 itself) but it has not an open SVN and development is quite closed. Another note: only community support is for free.

Dojo is more polite with licensing and it’s released under BSD, but I don’t like the graphic layout too much and the way you’ve to code your applications writing a non-standard HTML with dojo-only attributes. It has some accessibility features.

Some considerations:

  • In my tests I found bugs in both frameworks
  • porting P4A to one of these tools is a “1 way road”
  • relying the rendering layer to a 3rd party project means we’ve to 1000% trust this project
  • these tools do not have a good print CSS support

We would have a 3rd option: continue on our road with quite standard HTML but rewrite our CSS from scratch with a CSS reset and a modular design which will give us better control.

I wrote extjs developers to know if they’re interested in a collaboration with P4A, I’m waiting for an answer but I’m looking for your considerations too, community it’s important to me, please let me know what you think and what are your experiences with those tools (or suggest others).