I’ve been dormant for quite some time, mainly due to a major project going on at work. This week I’m starting my vacation, and its time to get back to all things fun. Today I got offered a spot on the Prado Developer Team, which I hope will prove to be both a challenge and a great opportunity to improve my knowledge on both the framework and PHP.

As a part-time project I’ve started building a multi-touch display surface inspired by Microsoft Surface. I’ve completed a *very* basic edition (tutorial here, and I’ve just started planning a more complicated setup along the lines of this project.

I’ll do some posts on the process as soon as I get some pictures.

[tags]PHP, Prado, Multi-touch[/tags]   

Aug 262008


After receiving quite some feedback on my post “Why Delphi for PHP should have used Prado instead of VCL” I decided to do a follow up to that post. Some of the feedback was quite interesting, hence this post was born.

First and foremost I’d like to address the feedback I got regarding the class name prefixing in VCL/PHP. I argued that the lack of class prefixes could create problems in the future, and used Prado’s T notation as as sample of something that would at least be a bit better. Let’s take a look at two VCL/PHP classes named Collection and Object. These two names are often reserved in programming langues (atleast object oriented ones). If PHP decides to introduce these two classes the VCL/PHP guys would be pretty screwed. It would involve refactoring the framework as well as applications which uses those classes. Prado on the other hand has a prefix (TCollection etc. minor, but it’s a world of difference). I assume that the VCL/PHP authors will introduce namespace support with PHP 5.3, so this issue will hopefully be a thing of the past when 5.3 ships. That said, I’m a bit curious to see how the migration / backwards compability would turn out if VCL/PHP adopt namespaces.

What I miss in the feedback I got from my previous post was people acually using VCL/PHP for enterprise applications and how that is working. From what I can tell the usage of Exceptions is still limited to the 3rd party libs such as Zend Framework which are included with VCL/PHP. That’s a bit interesting.

I’d like to touch on the comment made by Pieter Viljoen for my original post. I agree that Codegear pushed quite a toolset for the PHP community in a short time, but the underlying code is not enterprise quality. One can argue that PHP is ugly and flawed (not sure I agree on that part), but that does not mean that one should not strive for good architecture and methodology when developing frameworks on top of PHP. I see the point that VCL/PJP offers features that are interesting for starting PHP developers, but for large scale applications I just don’t see it. I’d be pretty cautious pulling in a framework without exception support if I was to create an application.

Again, I’m really interested in some feedback from someone that actually has built applications with VCL/PHP.

I’ve also noticed that there is not much activity in the VCL/PHP SVN repository. Anyone know what’s going on there?

[tags]PHP, Prado, VCL4PHP[/tags]  


My favorite PHP framework just got a new release, adding several new components and fixing 30-ish bugs. The bundled JavaScript libs (Prototype / script.aculo.us) have also been upgraded, so that should help lots of people struggling with the old versions. Head on over to PradoSoft.com to download the new version. If you are new to Prado, I recommend checking out the Prado QuickStart tutorial.

[tags]PHP,Prado,Frameworks[/tags]

I recently went to a presentation where some guys from CodeGear showcased Delphi for PHP and VCL4PHP. It’s a new product which enables PHP developers to use drag / drop and wysiwyg methods to build applications with PHP. The IDE uses VCL4PHP as the underlying framework.

This kind of tool is something that ASP.net has had for a long time (ie Visual Studio.net). Not only does it make the development process easier when it comes to building applications, but it also handles setup of applications, default configs etc. Until now there hasn’t been any tools for doing this with PHP, so I sincerely congratulate CodeGear on getting something out to the masses. Their IDE is a really nice tool with lots of potential. It ships with apache, and has lots of nice features like a integrated debugger etc. The immediate draw-back is that it runs on Windows only. My impression is that most PHP developers (atleast above hobby level) works on Linux based workstations, so I imagine getting a strong user base could prove to be difficult.

Now, why do I think that Prado is far superior to VCL, and why would it have been a better choice:

1.Exception handling
Any framework which are viable for larger scale application development should use exceptions. It’s an established way of controlling code flow and making sure the code can recover from error.

VCL: This is the first MAJOR flaw which would possibly be the hardest to fix. I’ve spent some time looking around in the VCL code, and there is some basic exception handling here and there. The problem is that most of the controls does not have any exception handling at all. This makes it very hard and tedious to control the follow when errors occur.

Prado: Usage of exceptions throughout the whole framework, with the possibility to have custom exception handlers lays the foundation implementing proper flows in the application and user friendly feedback when errors occur.

2. Usage with other PHP frameworks
A framework needs to play nice with other framework these days. There is no framework that has everything, so the coder will most likely use any given framework in addition to something else.

VCL: None of the controls I’ve seen while checking out the VCL source code are prefixed. Having controls with class names like ListView, PageControl, TreeNode etc won’t play nice with other frameworks. Also, using class names like Object and Component isn’t something you’d want to have in a framework.

Prado: All components in Prado are prefixed with a ‘T’ like TLabel, TPage, TListView ensures cooperation with other frameworks.

3. Generation of HTML code from controls
VCL: The controls implement a method called dumpContents which basically writes HTML and JavaScript tags and attributes by using echo. Some sub classing is done where the parent renders as well.

The following snip is taken from their CustomLabel code:
552 if (trim($this->LinkTarget)!=”") $target=”target=”$this->LinkTarget”";
553
554 $class = ($this->Style != “”) ? “class=”$this->StyleClass”" : “”;
555
556 echo “<div id=”$this->_name” $style $alignment $hint $class”;
557
558 if ($this->_link==”") echo “$events”;
559
560 echo “>”;
561
562 if ($this->_link != “”) echo “<A href=”$this->_link” $target

By letting most of the controls be responsible for writing the low-level HTML code it’s much harder to keep the code XHTML valid, and does not exactly scream re-use. See next point for how Prado handles this.

Prado: Controls that render contents in Prado extends TWebControl. I’d like to quote the Prado manual for TWebControl here:
“TWebControl is the base class for controls that share a common set of UI-related properties and methods. TWebControl-derived controls are usually associated with HTML tags. They thus have tag name, attributes and body contents. You can override getTagName to specify the tag name, addAttributesToRender to specify the attributes to be rendered, and renderContents to customize the body content rendering. TWebControl encapsulates a set of properties related with CSS style fields, such as BackColor, BorderWidth, etc.

Subclasses of TWebControl typically needs to override addAttributesToRender and renderContents. The former is used to render the attributes of the HTML tag associated with the control, while the latter is to render the body contents enclosed within the HTML tag.”

4. XHTML code generation
Producing valid XHTML is something we should all strive to do. Not doing so may result in display problems in most browsers.

VCL: I tried to validate a basic demo site created with Delphi for PHP and VCL4PHP. The results speaks for them selves. The generated HTML code is not XHTML compliant. Example from the CustomLabel code again – echo “<A href=”$this->_link” $target. Remember that XHTML tags are always lowecase. There are several other problems as well, and the validation link shows some of them.

Prado: The HTML code that Prado generates is mainly done in the parent controls, so keeping the base implementations XHTML valid mostly ensures that the child controls will be as well. This also removes the actual rendering code from the controls, so creating new controls is far easier and cleaner.

5. Validation controls
Input validation is some of the most boring tasks when writing web applications, and it can be fairly difficult to get it right.

VCL: According to the guy from the presentation there is none, but I found a screen cast here. It seems way more tedious than the Prado way, and I can’t tell if it’s released or just in trunk / testing at the moment.

Prado: Prado ship with several validation controls which works both client side and server side. TRequiredFieldValidator, TRegularExpressionValidator and TEmailAddressValidator ensure that the coder can feel very safe when it comes to validating input. TCustomValidator lets the user create custom validation logic to perform tasks (for example login checks). A complete list and usage examples can be found here.

6. Encapsulation
Encapsulation is a way to make sure that the internal state of classes isn’t messed with by code that should not be able to.

VCL: I’ve been looking trough the code trying to find controls that actually use private methods for managing their internals. As far as I can see there is only a fraction of the controls which uses private methods, and when they do it’s only for one or two methods. This is a design no-no when everyone can call everything.

Prado: Only methods which have to be public are public. This ensures proper encapsulation and prevents the coder from accidentally messing up the state of a control.

7. Component properties

VCL: Delphi for PHP stores all component properties in XML files. I see the point of doing this for the sake of the IDE, but when it comes to runtime code I do not. During the demo they showcased how to use smarty templates with VCL, and to add a control which was created in the RAD gui they use markup ala {button1}.

Prado: Prado separates the code and login into two files (.php which holds the page class, and .page which holds the markup). The properties for the components are kept in the .page files which is a much easier way to look at the controls when creating markup. Check this link for a quick intro to how Prado handles this.

8. Usage of globals
VCL: Using globals? We all know this is bad and belongs pretty much belongs in PHP4 applications. If you need a dirty hack it can be a last resort kind of thing, but using it throughout the whole framework?

Example of globals usage:
30 $exceptions_enabled=true;
31
32 global $use_html_entity_decode;
33
34 $use_html_entity_decode=true;
35
36 global $output_enabled;
37
38 $output_enabled=true;
39
40 global $checkduplicatenames;
41
42 $checkduplicatenames=true;

183
184 /**
185 * Global $application variable
186 */
187 $application=new Application(null);
188 $application->Name=”vclapp”;
189

These things should be config related and stored in either the application object or a core base class.

I also checked out the blog demo from this page, and usage of globals can be found throughout the applications (global $BlogDB, global $AdminDeleteComment etc).

Prado:
Prado uses globals in one single file, and that’s the file responsible for generating client side scripts. Settings which span the whole application can usually be accessed from the application object.

9. Ajax

I’m considering to do another post comparing the ajax features in depth, but I just wanted to point out one thing seen in this screencast on AJAX. The coder escapes from PHP to write the javascript, then jumps back into PHP. In Prado things like these follow the same design as the rest of the framework.

Conclusion

I want to do some more in depth comparisons of controls and ajax support later on, but my current impression of VCL4PHP is that it’s “out of date” or not quite on a professional level. Not taking advantage of PHP5 features like interfaces and encapsulation, lacking proper exception handling, key features like validation and not generating valid XHTML code are all major points which I would expect a proper framework to have in place. One has to wonder why CodeGear went in this direction.

If you consider using VCL / Delphi for PHP I recommend that you first stop by the VCL4PHP forums to get some impressions on how people are using it and see their experiences.

I would really like to come in contact with someone that knows VCL4PHP so that a in depth comparison of the different controls can be done.

We’ve been working on getting drag-drop features to work in Prado for a while now, and we got it on a level which fills our needs.

The current state lets you register drags, drops and drag-drop. The most annoying limitation we have at the moment is that you only get the drop container on callback. We currently slip around that by sending our data with the callback parameters.

The demo attached here shows dragsdrops (green), drags (yellow) and drops (blue). When an element is dropped the label is updated with the name of the drop element and the callback parameter data. The callback data is currently set up in the js file and it’s only set for the dragdrop elements, but there should be nicer ways to do this.

The component only uses javascript that ships with Prado, so no external libs are required. The actual MyDraggable php class is based on another Prado component, and it probably needs some cleanup as well. The demo ships with Prado 3.1, so just unzip and set correct permissions.

Kudos goes to my co-worker Lars-Olav for getting the client side stuff to work. Javascript is not my strong side ;)

Online demo – http://prado.eirikhoem.net/dragdropdemo/www/
Download source – http://www.eirikhoem.net/dragdropdemo.tar.gz

Update: Source file is not up to date. Will fix asap.

Aug 112007

When I first started using PHP on a larger scale I didn’t have any experience with frameworks, so I started creating some minor helpers which made my day easier. After my first project I came across Prado. Since I had been using .net previously I grasped the concepts really quickly, so it was love at first sight. It took around a week to get fully productive with Prado, and it’s saved me countless hours of nitty gritty work. Since I first started using Prado I’ve found the forums to be the best source for information and support when I can’t find help in the documentation. The community around Prado isn’t that big (yet), but there are quite a few people which are very active. At first I can be a bit hard to navigate around the available resources, so I’ve composed a list of links which is worth checking out:

A few nice-to-know links and blogs related to Prado:

Planet Prado
Pulls data from most of the major Prado related bloggers. Nice place to stay up to date on what’s going on in the Prado world.

Prado Roadmap
The trac-based road map for the Prado project. Shows the current milestones and planned releases, with information about which features to expect, which bugs are reported and so on.

Prado Blog Tutorial
A step-by-step tutorial on how to build a blog using Prado. Nice place for beginners wanting to learn Prado

Prado Quickstart Tutorial
The term tutorial isn’t quite fitting, since it’s more of a reference. The Quickstart is a nice reference for control and component usage in addition to documenting severa key features and concepts in the Prado framework.

Prado Component Repository
Trac set up for user-submitted components and controls. This project is still in the early stages, but worth keeping an eye on.

Prado Community Project
The Prado Community Project is a new project created by the most active users of Prado. The goal of this project is to ensure that Prado gets a growth in both users and material. There are several projects planned which looks very interesting. If you have some time to offer, please stop by the forums and help us out.

There has been lots of interest in the AJAX (active controls) features in Prado lately, but the lack of client side controls has been a turn-off for many. The area that’s gotten most request is drag / drop. Prado 2 had controls for this, but it’s been absent in Prado 3. Several users on the forums has been trying to get it working, but nothing has ever been completed. The main issue has been the communication between the client side scripts and the server side control (callbacks). I’ve spent some time digging trough the Prado code and created a concept control which fires a callback.

Code:

MyDraggable.js code

MyDraggable.php

Home.php

Home.page

Stay tuned for Part II which hopefully shows something more useful :)

Jul 022007

Earlier today the Prado team released version 3.1 of the Prado Framework. The new features includes AJAX support trough Active Controls, some cool new database support and various other new services and controls. Go here to see the release announcement.

May 242007

I spent some time figuring out how acegi tokens works and how to use them with Prado in PHP. An acegi token is a hash-key-ish token that you can use to identify yourself with a web service instead of signing on with user-name and password for every page load. The way this works is as follows:

1.) First time, sign in with username and password
2.) Soap server returns a ageci token and sets in in a cookie on the soap client
3.) Grab the token and store it across page requests.
4.) All subsequent calls, set the token in the soap clients cookies.

The token stays the same across the whole session. I’ve experienced two different behaviours when it comes to returning the token. Some services returns the token with each response, while other services only return the token on the first call and sends null in the subsequent calls. There is one exception to the first, and that’s when I encounter soap-faults. The token seems to be null with those no matter what.

It took me some time to get this right. I had never worked with acegi tokens until last week, so I was pretty much blank on the topic. Google didn’t offer much in terms of samples with PHP.

When a user signs on for the first time I connect to the web service in the user login method in the Prado user-manager. I make sure the token is returned and I store it a field in the user object. The token is encrypted, but I do some extra magic to make sure everything is as secure as possible. The token is then serialized and stored with the Prado user object. On page load I make sure to retrieve the token from the current user and set it for the service. This is done in the preRunService method in a custom TApplication class.

It’s been a few days since I got this implemented now, and everything seems to work very well. It’s nice to have the extra layer of security so the user-name and password can be used once and then thrown away.

I’ve got a upcoming project that requires some complex interaction services and I’m looking around for frameworks that suits my needs. Almost everything I develop gets done using the Prado Framework. The AJAX support in Prado is pretty new (at least for the 3.x version), so I’ll probably need something that offers more in terms of integrated services and controls. Prado supplies some of the underlying features, but I do not have the time to re-invent several wheels. I know that there are plans for new ajax features and controls in Prado 3.1, but I can’t sit around waiting for that.

It’s been quite some time since the first time I heard about the Backbase framework. I’ve never gotten around to take it for a spin, but I’ve spent some time reading the documentation and checking out the samples. The Backbase Travel Demo is especially impressive. The controls and widgets that ships with the package are pretty impressive as well. I hope to get time to give it a spin this weekend. If I do I’ll do a short writeup on my impressions and experiences.