PEAR

Seeing Davey's missery, and Sebastian's / Kristian's fixes to Serendipity to stop trackback spamming. I struck me that perhaps trackbacks combined with blog spammers are always going to be a disaster waiting to happen.

The concept is quite nice, being able to see related articles, when reading a blog, but the trackback concept is a little too trusting, unless you want to go in and moderate trackbacks.

It inspired me however to hack up a smart referer log for my blog entries. (visit the site to find out more..)

View Extended Entry

Posted by in PEAR | Add / View Comments()

Alot of people started using blogs as a slightly better media for technical information, but it's becomming evident that with subjects ruby on rails, and some of MS astroturfing with marketing material, that blog aggregators like Artima have been abused heavily with rather second rate blogging, about 3rd rate tools.

While ruby on rails is probably a good tool, it fails in a huge part from the flawed thinking that one provider can deliver a complete solution. It took me a long while to realize that attempting the complete toolkit that ror promises is often fruitless. It rarely delivers much beyhond the intial demostratable examples. What normally happens is that in designing for a single solution (A super fast web interface to databases), you often end up with libraries that are rather poor for generic usage.

The fact that PHP already has 3 or 4 projects that are based on PEAR, that deliver pretty much the same solution as ror. Indicates that the concept of small flexible libraries, maintained by seperate individuals, rather than one super mega project is always more valuable, although I guess you miss out on the hype more.

View Extended Entry

Posted by in PEAR | Add / View Comments()

After quite a few email conversations about HTML_Template_Flexy, I finally got round to documenting one of the javascript libraries I've modified. This is still a bit buggy around the edges, but is pretty much working.

Javascript Calendar started off with a few hacks around the dynCalendar on pear.php.net, and evolved into nice clean simple Calender renderer.

The main design criteria for this was that it should be independant of the HTML page, not requiring any specific javascript, or changing the backend Template code. Just include the javascript file, set the style, and add a few extra attributes to the input elements.

View Extended Entry

Posted by in PEAR | Add / View Comments()

I've been working on a typical web application, and given the fact that deadlines are not a big issue for a change, a little focus has gone into thinking 'is there a better way to do this?'

The challenge is really, how to do client side javascript validation and at the same time add the ability for flexy to pick up the calls and perform the matching serverside validation..

Like alot of my client side javascript, i'm going with a model that basically involves adding these lines to the end of the file:

<script type="text/javascript" src="/js/validate.js" / >
<script type="text/javascript">
//<!--
Validate_onload();
//-->
</script>

The onload method adds a onsubmit hander to all the forms, and which in turn looks for all the input elements and does the required validation.

I've tended to avoid onchange handlers on the form, partly as I feel it is a bit confusing for an end user to be continually be reminded that they have got something wrong, even while they are filling in the form (and perhaps havent finished entering the data)

the onload'er method is also quite nice, as it doesnt involve to many changes to the form.

Now comes the crunch.. where to add the checks for validation, A long while ago I tried something like this:

<input name="age" validate:rule="isempty();number({ min: 8, max: 100});">

Using javascript, it should be easy to extract the rule, split it on the ');' bit, and eval each of the expressions, using the input's value.

On the Flexy side, it does involve a little messing around to convert the tests to pear's Validate class, but the principle is quite nice in the fact you can test the validation just by viewing the template, without actually installing it in the application and running it through the template engine.

Javascript allows me nicely to change the background colour if there is an error (either directy or setting it's style), but again another issue raises its head:
Where do I put the message about what is wrong.

• On the simple version you really want it to stick add a div layer, and put a message under the box.
• On a more complex version, you want it to pull the phrase from a hidden element on the page, and display a translated version if applicable.

The other thing to consider is how to re-integrate the error messaging with stuff coming back after a post (on the extremely unlikely situation these days that someone has turned of javascript )

But at least it did make me think that I should javascript enable the comment boxes on my blog, only making the comment box appear if you are using javascript.. - at least it should stop a few blog spammers.

View Extended Entry

Posted by in PEAR | Add / View Comments()

I have a whistle stop trip over to Frankfurt for my one talk PEAR and PHP5, at the PHP Conference. Sad thing is, that I arrive on monday evening, and fly out wednesday afternoon - so I guess other than jetlag and my talk, I'm not going to get too much done..

Anyway - come and see the talk, if you want to see all the gotcha's for PEAR & PHP5..

View Extended Entry

Posted by in PEAR | Add / View Comments()

I recieved a very nice email, enquiring about some of my code hosted on my dev server. For those not in the know, I try and keep my libraries in
http://devel.akbkhome.com/svn/index.php/akpear/

This includes alot of my non-pear submitted code, Why not submit it to PEAR, you may ask.

• Maintainance - until the bugs and feature requests calm down on my existing packages, I'm already stretched quite far.
  
• Standards - PEAR standards are very strict (for good reason), but For some of the code, which I use once, adding full documentation is often not within the budget.
• Proof of Concept - eg. DWG_Parser, which could be improved to solve a bigger issue. But I've not got the time/budget to do that, so it lives as a proof of concept, and a starting point if someone wants to use it.
  

Some of the highlights include

• HTML_FlexyFramework - url to object loader and mapper
  
• Config_Singleton - 1/2 finished generic Config Store.
• DWG_Parser - read Autocad Dwg files (extracts the icon only)
• Gtk_ValidateManager - really a HTML form validation framework (interface to build validation rules, and runtime code to apply them to HTML pages.)
• HTML_DataObject - browse and edit code for automating browsing of databases and updating them. (This is about the 3rd effort at this, and it's still got serious issues. - but it does work!)
• SpreadSheet_Generic - a tool that at present, can load a Gnumeric file, and write an XLS file, with templating and block replacement abilities.
• XML_SvgToPdf - takes SVG (from things like sodipodi, writes PDF's - with facilities for templating)
  
• Backup_DVD - a nice routine to automate backing up of data

Along with this, a few projects I've worked on , the clients have allow to code to be open sourced, These tend to be highly specialized projects, so that making a big fanfare of their existance is not really that usefull. However they do provide a good illustration of some of the PEAR classes.

Interestingly if you look at the code size for each of the applications, the size of the library folder (eg. pear) is at least 3 times larger than the source code! - pretty good code reuse.

The two key Projects that are available are:

Hebe
http://devel.akbkhome.com/svn/index.php/hebehaven2/
A Yacht club Membership management, billing application, It illustrates alot of the code above in action. I wrote this in 2003, and still make minor updates, but the project is paid for and pretty much done.

Since this project was done, I've stopped using certain features of the design.

• The default entry page class in Hebe is Hebe/index.php (Hebe_index)
• In later projects the base class matches the project name = eg. Hebe in /Hebe.php
• The template folder was in the top level folder eg. /templates
  
• In late projects that was move to the Project folder eg. /Hebe/templates

FlexyShipping
http://devel.akbkhome.com/svn/team.php/flexyshipping5/
This is a Shipping management application in XUL, I did the specification and outsourced it to a team to build. After the majority was completed, I took it back onboard, and have been working with the end user to complete all the features they want.
It is interesting for a number of reasons other than just using XUL (which simply blows away HTML for intranet applications)

On the positive side:

• It meant alot of additions to HTML_Template_Flexy to support XUL.
• There is a very nice library in there for form submiting of XUL interfaces (and some nice tree stuff) common.js
  
• The code design while not perfect enabled the outsource team to work on a simple concept, and ensure that it was maintainable when It went into the feature finalization stage.
• Due to the Intranet nature of the project, almost all the data validation is done client side.. (so in theory we only check if the return values from update/insert where ok on the server side).

On the not so great side

• There where initial problems that the contractor didnt know how to use DataObject correctly (and missed some of the key features, eg. setFrom(), factory()
  
• The file layout (alot of layered directories is an absolute pig to maintain.. ) eg.
• FlexyShipping_Add_Order_Item was in FlexyShipping/Add/Order/item.php
  
• This should have been FlexyShipping_OrderItemAdd,
  most of the generic subclasses should really have ended up in the top level directory, with perhaps only some of the more specialized page classes in a 3rd level folder (like reports perhaps)
• There is a considerable amount of repitition (eg. lots of small classes which do little more that list/get/set )which something like HTML_DataObject solved in Hebe. However I suspect that this is actually clearer than the HTML_DataObject solutions, which eventually become horrifically complex.

Akbkhome
Of course the latest in the line of projects is the akbkhome website, which is trying to make highly modular the whole Framework concept, with some mixed success. which can be seen now via it'self

View Extended Entry

Posted by in PEAR | Add / View Comments()

I've been having a little attempt revamping my subversion viewer, seeing if I can

1. Integrate it into the new site
2. Use VersionControl_SVN, rather than the quick hack I wrote, Subversion_Stream.

I have to admit, though, the API for VersionControl is not exacly clean and user friendly. This is a general overview of the gripes.

• Uses PEAR_ErrorStack, which hides errors, even worse than PEAR_Error used to.. DataObjects uses a ErrorStack style system, you can print_r the dataobject, and it shows you the last error as a propery of the object... (simple).
  
  Error stack seems to insist on you loading it, then only using it's methods to check stuff. - the actually error is hidden away in the stack object..
  
  Trouble is, that a number of the functions in DataObjects needed to return true/false (fetch, for example), so returning an PEAR_Error, was problematic then (in hindsight, alot of the other methods should have returned PEAR_Error, but that broke BC - and in the future it should throw exceptions).
  So, DataObjects had some logical justification for messing with the standard a little, VersionControl_SVN hasnt really, and it just adds a dependancy on a eventually redundant package.
  
  
  
• Trying to make things easy ending up with a messier API,
  
  $x = VersionControl_SVN::factory(array('list','cat'), $options);
  $x->list->run()....
  
  while this is cute, it adds an horrific amount of complexity to the API, and only saves you a little bit of typing, at the expense of clarity and readibility.
  
  
• Counterintuative program flow.
  

class VC_SVN {
.... function run() {
....... $this->prepare();
....... exec in here..
....... $this->parseOutput();
}

VC_SVN_List extends VC_SVN {
..... function prepare() {

So you call run on the base class, and the body of what happens is in the extended class. - so if you look at the 'action' classes, it is impossible to follow the flow of the application, without having a perfect memory of the base class..

it would have been far better to have a run method in each action class, and call some generic methods from the base class.


• direct API mapping makes it a little unclear how it should work:
  example -
  
  require: svn list -v {mysite}
  
  command:
  $svn->list->run(array({mysite}), array('v'=>true));
  
  (and if you get it wrong, not much happens)
  ok - how is this simpler than:
  $svn->run('list -v ', $mysite);
  
  

View Extended Entry

Posted by in PEAR | Add / View Comments()

Sometimes, it's those little problems that have annoyed you for years, and you never bothered looking at how to solve them. Today it was alternating highlights on a table.

A horrifically simple problem, rendering a table of data, and to make it easier to read, you alternate the rows with a light grey background. I did a whole application, that was heavily focused on displaying data like this, and came back this week to add an extra page.

The old code did a standard DataObject/Flexy Template trick:

$hightlight = 0;

while ($do->fetch()) {
	$r = clone($do);
	$r->highlight = "row" . ((int) $highlight);
	$hightlight = !$highlight;
	$this->rows[] = $r;
}

and in the template:

<tr flexy:foreach="rows,row" class="{row.highlight}">
	<td>{row.somedata}</td>
	...
</tr>

Ok, that wasnt too bad, but somehow the messing around in PHP each time, just to do the highlighting felt kind of messy.., I had looked at this again recently for another project, and discovered there is a way to do it using CSS2 (but IE doesnt support it.. - what a supprise). I had also seen another suggestion, adding a behaviour to the style for the table, this seemed reasonable, however, when I'm prototyping, I like to keep things together, so it was a bit annoying to have this loose bit of javascript hanging around in a file on it's own.

So today I got a bit closer to an ideal solution.

while ($do->fetch()) {
	$this->rows[] = clone($do);
}

And in the template:

<script type="text/javascript">


function highlightTables()
{
	var tables=document.getElementsByType('table');
	for (var t = 0; t < tables.length; t++) {
		if (tables[t].getAttribute('class') != 'stripes') {
			continue;
		}
		oRows = tables[t].rows;
		var   len = oRows.length;
		for (i=1; i<oRows.length; i++) {
	        	oRows[i].setAttribute("class", 
				(oRows[i].rowIndex % 2) ? 'row1' : 'row0');
    		}
	}
}
// run it on load, or just call the function when you startup.
window.onload = hightlightTables

</script>

<tr flexy:foreach="rows,row" class="stripes">
	<td>{row.somedata}</td>
	...
</tr>

View Extended Entry

Posted by in PEAR | Add / View Comments()

Seeing mention of XML_XUL, the PEAR package on a few blogs and in PHPMag, I thought it might be worth mentioning that I did evaluate using it for a project a while back. At that point, the code was not mature. However, It was already clear that the concept behind it is pretty flawed.

XML_XUL, offers a couple ways of working
a) Read a XUL file, convert it into Big tree of XUL Elements, Manipulate it, then render it.
b) Start from scratch, building the whole tree manually PHP, and render


Both of these have huge memory issues, a) has performance issues of often needless requiring the parsing of XML. b) has a fatal flaw in that it totally obliterates the potential to wysiwyg edit the application.

In the end concluded that using the Flexy engine, was far more efficient, as we could prototype the look and feel (and easily make major changes late in the design process) without having to mess around with the code to much. (It's also mindblowingly faster).

It did not however go without having to make a few additions to Flexy.
a) allowing "<html:input" with Flexy's Element parser (so we could do file upload in XUL)
b) using id="this_is_a_tag" and being able to compiler and render parts of a file using the id tags: $flexy->compile("template.xul#this_is_a_tag);
c) Quite a few XML parsing additions to the Tokenizer (<?xml-stylesheet....)

While XML_XUL remains cute (and may even provide a reasonable way to add XUL elements to a Flexy Template) , I do ponder if just the ability to use the PHP DOM extension along with Flexy may be far more powerful, and doesnt involve learning a whole load of API's. - Time which is far better spent learning Javascript/W3C/PHP DOM (which are all pretty much identical).

View Extended Entry

Posted by in PEAR | Add / View Comments()

PEAR dev is hot with the exception fever at present, The OO purists are beating down the door requesting the eviction of that horible legacy of a bygone age, PEAR_Error. And hoisting the flag of the Exception god at the gates.

Well, It's not really that bad, but it made a fun read. But as Jeff Moore Points out, Exceptions in PHP5, will (and have now) open a whole new can of worms.

Probably like alot of people, with this on the horizon,I have been interested to see last years timely ramblings of Joel that exceptions are evil, not that I always agree with him, but his arguments are rarely too flawed. There followed a huge weblog back and forth about the Greatness and Disaster that Exceptions brought (all this without any reference to the earthquake about to occur in PHP).

I've generally suffered with exceptions, I've hacked on programs written in C#, Java and Python, and found that errors raised by Exceptions tended to be very cryptic, and confusing messages. Perhaps partly due the lack of context information, like line numbers, that is displayed by those languages. But probably Just as frequently by the horrific coding of

throw new MyWgtException()

Ok - so you have your own exception class, but am I expected to guess what the authors abbreviations mean?

One of the beautys of PHP4 is that it allows you to do simple things simply, and complex things without the hastle. Without exceptions, It's very easy to let things fail, and not care about it. Ok, it's not perfect programming, but There are levels of failure that you really do not care about. PHP's often emits E_WARN on a variety of code (reading from unassigned variables etc.), that would not justify a Exception. Similarly, In PEAR, there are many situations where if something failed, It is not that critical.. (like updating a database row, but there is no new data applied).

I do ponder sometimes what would be the answer for Exceptions, is throw always the way to go?

function myblobby() {

    return new Exception("There was a problem with myblobby()");

}

function myblobbyDie() {
    throw new Exception("There was a problem with myblobby()");
}


$object->myblobby()->doSomething();

Could that be made to throw an Exception, even though the myblobby call is not normally fatal? could this be done? - without the intervention of PHP core?, possibly?

class Log_Exception extends Exception {

     function __call() {

            throw $this;

     }

     function __get() {

            throw $this;

     }

     function __set() {

            throw $this;

     }

}

Realistically, PEAR classes should probably impliment their own exceptions (eg. Log_Exception), the theory always was that, Packages where supposed to implement their own _Error class, that included usefull things like translations of error messages..

Just returning exceptions, rather than throwing them, at least goes some way towards making them more usefull, although it would be better if PHP core could check if an Exception was returned, within a try {} catch () {} block, that catch was actually called..

View Extended Entry

Posted by in PEAR | Add / View Comments()