Category Archives: Things I do

P4A 3.8.2 is out!

This is a minor release but it contains really a lot of great upgrades and fixes, here you’ve the changelog:

- Zend Framework was updated to 1.11.6
- CKEditor was updated to 3.6.0
- jQuery UI was updated to 1.8.11
- requirejs was added
- P4A_Dir_Source automatically sorts files
- P4A_Dir_Source::setPageLimit() calling was disabled
- P4A_Dir_Source’s page limit is now set to 0 (disabled)
- autocomplete values are now sorted and unique
- P4A_Field::getSource() method was added
- p4a_load_js now uses requirejs
- P4A_Field and P4A_Data_Fields now support the “datetime” type
- P4A_Field and P4A_Data_Fields now support the “time” type
- P4A_Object::dropImplement() now turns the action to lowercase
- deprecated method P4A_Object::dropMethod() was removed
- a javascript bug with P4A_DB_Navigator’s drag&drop functionalities was solved
- P4A_DB_Navigator now correctly supports source with non-default DSN

Download P4A 3.8.2

Probably the best WordPress LinkedIn profile plugin :-)

A few weeks ago I was working on my Italian professional website and I wanted to use my LinkedIn profile as the website’s home page, I tried some of the existing WordPress LinkedIn plugins but none of them was working (they use a bunch of complex regex that are really easy to break, if LinkedIn changes its pages a little bit all of them won’t work, and that was the case) so I started to write my own LinkedIn resume plugin.

I used a different approach using DOM parsing and I think that will be absolutely bulletproof :)
It also outputs raw parts of LinkedIn HTML so it’s much easier to style and we’re sure that it will include every future feature LinkedIn may add (also without my intervention), I think that’s a great plus.

Release 1.3 it’s available right now and the plugin (available under GPL license) is right there for you to download and use for free.
Check it out!

UCK 2.4.4 is out!

A new maintainance release is ready just for you, giving you full natty compatibility, here’s the changelog:

———–
– 2.4.4 –
———–

* Frontend:
* Fixed usage message in uck-remaster to match the parameter handling
that was already implemented.
* Start message now contains output of uname and lsb_release. This
should help to better diagnose problems.
* customize script now outputs kernel and lsb_release info. This
should help to better diagnose problems,
* uck-gui now gives proper usage message and outputs uname and
lsb_release information.
* uck-gui now passes REMASTER_HOME to uck-remaster. Necessary for
changed behaviour of sudo in Natty. Fixes (#748209). Answer
questions #151311, #151108, #150223
* Backend:
* Extract proxy environment variables in uck-gui and pass them on to
the chroot environment around sudo calls. Solves (#111253)
* Modified customize_iso to correctly use REMASTER_HOME if SCRIPT_DIR
was not specified.
* Documentation:
* Fixed uck-gui man page: uck-gui does not accept a customization-dir
parameter.

Download UCK 2.4.4 or use our stable PPA.

P4A 3.8.1 is out!

A bugfix release for the 3.8.x serie, if you’re using P4A be sure to update to the new release, here you’ve the changelog:

- jQuery was updated to 1.4.4
- a bug with multiple p4a_load_js calls (with the same url and within the
same loading cycle) was solved
- a bug with MSSQL and query limits was fixed (thanks to Diego Fattori)
- CKEditor was updated to 3.5
- P4A_DB_Source::getRowPosition() now returns 1 if the query throws an error
- P4A_DB_Source::addHaving(), setHaving() and getHaving() methods were added
- Zend Framework was updated to 1.11.2
- a bug with P4A::restart() method was fixed (thanks to Daniel Carrero)
- a bug with P4A_Data_Source::saveUploads() and custom file paths was solved
- a new technique to unload CKEditor was implemented

Download P4A 3.8.1

- UPDATE: due to a SourceForge downtime P4A 3.8.1 tarballs can’t be downloaded at the moment, I’ll update this post when everything will be up again, in the meanwhile you can check out the P4A SVN (tags/3.8.1).

- UPDATE 2: SF should have fixed the problem, P4A 3.8.1 packages are available right now.

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.