Why use UNIPS? It is a bunch of nitty-gritty classes. Most of them can be used in a standalone way, a couple depends on PEAR.
With its HTML package UNIPS proposes a non-standard way to generate frontend code for the browser. As often told, “PHP is a powerful templater language itself”, so here we have a solution of standard DOM components. PEAR has a similar concept but it is not generalized enough. UNIPS gives you more degrees of freedom.
The HTML package is based on the class UNIPS_HTML_Tag which can be used as following:
-
$tag = new UNIPS_HTML_Tag (‘input’);
-
$tag->setClass (‘myInput’);
-
$tag->setAttr (‘type’,‘password’);
… and so on. Of cource you could write it as a fragment of static HTML code but this way you have a fully dynamic code creation: so it can be used if you need this. Based on this class there are implementations of mostly used tags.
-
$select = new UNIPS_HTML_Form_Select ();
-
$select -> setOptions ($arr);
The sense of it is that you do not need to write template code again and again.
Another interesting feature is that you can use an instance of the class UNIPS_HTML_Page to do things like dynamic loading and/or generation of Javascript and CSS:
-
$head = $page -> getHead(); // get the object for the <head> part of the document
-
$head -> addJSDef ($any_dynamic_js_code); // you could also create an instance of UNIPS_JS_Function
-
$head -> addCssImport ($css_file); // $head will check if $css_file is locally available an throw an Exception if not
Here is a very short example of PHP classfile generation just to give you an idea:
-
$class = new UNIPS_Codetools_PHP_Class (‘myClass’);
-
$class -> addMethod ($myMethod); // instance of UNIPS_Codetools_PHP_Method
Beyond this, there is a working RSA implementation and some things more - they are really generic but appear to be very useful in my real-life projects.
I hope I will have enough time to spend more time on writing the API docs but as they say - release early and I feel I better did it months before. If there is any public interest I will see which packages have more priority to be explained e.g. in tutorials.
You can download the current release package from SourceForge.net.
Possible drawbacks of this API might be that using lots of objects results in a bigger memory footprint as well as longer runtime. To adress this issue let’s take the CMS webfiks based on this API (29 KLOC itself plus 12 KLOC-extract from UNIPS plus almost 3 KLOC from PEAR):
- Memory: something between 8 and 10 megabytes. It is a lot for a script but for a CMS application not that bad - e.g. Typo3 requires 32 MB and more.
- Runtime (unoptimized server): okay, in the normal dev mode it is really slow, like 0.69 seconds. But in my opinion while talking about runtime we forget that the real runtime problem is first of all the time delay to get all the class and template files from the disk. Try to compile all your stuff into bigger libraries and you will see the difference. In my case it brought me to 150-300 milliseconds. All in all, still not too fast - but saved development time. If you need speed, there is more to it, if you compile all PHP to bytecode e.g. by the Zend Encoder. With it, my results were like 115 milliseconds. I am sure, that profiling and memory usage optimization (API as well as the application) will allow for achieving even better results.