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.

24 Responses to “Why Delphi for PHP should have used Prado instead of VCL”

  1. >”My impression is that most PHP developers (at least above hobby level) works >on Linux based workstations”
    Why? PHP is alive and kicking at many platforms. Windows as a development platform is pretty OK. No limitations.

  2. >Prado: All components in Prado are prefixed with a ‘T’ like TLabel, TPage, >TListView ensures cooperation with other frameworks.
    Using a prefixed T is as generic as not using it. No real advantage. But I agree on most other points. The reason I’ve choosen D4PHP is the promise of the 2-way editing and visual editor.
    But when it comes to speed, stability and scalability PHP, or ASP (or the like) will never be my choice.

  3. Henk:
    Thanks for your comments!

    I agree that PHP runs perfectly well on Windows as well as Linux. I worked from a Windows workstation earlier, but I swithed to Linux after a while so that I could compile PHP / apache in the same way as we run them on our production server. It’s just my impression, and I might very well be mistaken. :)

    When it comes to the prefixing I also agree that it could be better with Prado as well, but atleast Prado has a prefix. It’s way better than not having it, don’t you agree?

  4. All components are prefixed vith a T simply because they are named as the VCL for delphi components where.
    As you have said, most devs who picked up php ‘from scratch’ are likely to be working on linux, and they have grokked the http+html+css+js stateles model a while ago.
    This product is targeted to other shops, where delphi knowledge is strong and web development is weak: coders working on windows and knowing the std vcl like the back of their hands. It seems strange, but there are still quite a few places like that…

  5. Please correct broken link at the end of item #5 by removing the last character (parenthesis):

    http://www.pradosoft.com/demos/quickstart/?page=Controls.Validation)

    Thanks!

  6. gggeek:
    Maybe it was wrong of me to expect something which would suit developers without experience from Delphi, but the points about the weaknesses in VCL still remains valid. The IDE itself would be really interesting if it ran on Linux as well as Windows since it has lots of interesting features.

    J Bruni:
    Thanks. Updated.

  7. Great post Eirik, I agree with you on all points. VLC has a very hacked together feel to it. A reason that maybe they didn’t use PRADO is that some things in PRADO must be done just so which may have gone against what they were trying to achieve with VLC, but then PRADO is so easy to extend it’s seems crazy they didn’t just build a version of PRADO that works the way they wanted.

  8. [...] Hoem has posted some of his thoughts on why the CodeGear software package Delphi for PHP should have gone with the Prado framework [...]

  9. CodeGear didn’t go with Prado because it was already too late in the design phase of the IDE to change. CodeGear picked up the IDE from an independent developer who was planning on releasing the IDE as a free application. That developer had already rolled-his-own framework and built early versions of the IDE around that framework.

    When asked by members of the Prado community who wanted to see Prado as the underlying framework of the IDE, that was his (the independent developer’s) explanation: it was already too late in the development process to change. Then CodeGear bought/picked-up/ finished the IDE and released it as a commercial IDE. At least that is my understanding of why you see VCL and not Prado.

  10. [...] Why Delphi for PHP should have used Prado instead of VCL [...]

  11. Well done Eirik.
    I agree with what colson commented. And about T thing, I believe that its function is for programming consistency.

  12. [...] here is a good review of VCL for PHP framework [...]

  13. Now that D4P has been out for a while. We are seeing the effects of bad VCL4PHP design that you pointed out a long time ago.

    I for one think there is a market for a Prado based IDE on windows that will do what D4P tried to do.

  14. I researched this a little more today. I have to say that the IDE is great.

    Discovered that you can create your own packages and components in PHP. This tells me that may be easy to use Prado as the framework instead of the VCL4PHP. (Just replace base classes of V4P with Prado classes so ancestors are not executed) .

    I do not know how the IDE was coded to interface/parse with the PHP but at a first glance it appears a Prado framework to replace the current V4P is a possibility.

  15. ibandyop:
    Sounds interesting. I will look into this when I get some time.

    Thanks for the heads-up!

  16. You have to remember that Delphi for PHP was built for Delphi developers. Delphi developers love it and have done some pretty cool stuff in the year or so its been around. The VCL for PHP also functions similar to Delphi’s VCL.

    Prado, on the other hand, was a VS.net/ASP approach. CodeGear could have created VWD for PHP and used Prado. But they didn’t, because they’re Borland and they work with Delphi, not VS.net.

    By the way, most PHP developers would be developing applications on the Windows platform (especially with the better IDE selection), but many would have Linux boxes available for testing. Some development shops enforce purely Linux for development, testing and deployment. I personally use both; I VNC to my linux box from within my Vista-based laptop for the best of both worlds.

  17. I just used delphi’s latest version of their IDE (Delphi for PHP 2.0) and why they still choose not to use Prado or support it just beats me.

    It sucks compared to Visual Studio. I’ll be sticking with ASP.Net and Prado I guess

  18. You complain about the missing prefix in VCL/PHP, and use the T-Prefix of Prado as an example how it should be. The problem is, that the prado classes are obviously named after the Windows-VCL. In the Windows-VCL there are TLabel, TTable, TButton and so on. In the usual naming convention of Delphi T just prefixes a *Type* … “TLabel” just means “Type Label”. If the VCL/PHP had just used the original names from the VCL/Delphi, the classes would have been prefixed with an T, too. In fact, neither Prado nor Delphi/VCL used a product-specific prefix.

  19. But how I’d like to have a Prado based IDE, which would guide me through the enormous forest of Prado classes!

  20. Delphi for PHP 2.0 is out and their demo videos look awesome (that is till you actually use the IDE)

    Why these guys do not use Prado or support it beats me. I just tried it out and thought it was horrible. I’ll stick with Prado and ASP.Net

  21. Keep in mind that the Codegear had to work quickly to get tools people in the market needed in order to stay viable. So they focused on their core competency and released a whole range of products in a spectacularly short period.

    Delphi for PHP now provides the basis for the PHP community to rationalise and cleanup sets of standard component suites. So here is plenty of opportunity to extend or event replace the component libraries shipping with PHP.

    Much more can be critized about PHP than just the issues raised above. The language is fundamentally ugly and flawed. Point is their is a mass market out there which Codegear recognized and capitalised on. PHP is relatively lightweight, it is effective and the Delphi IDE makes it extremely productive!

    I disagree with the fact that Delphi for PHP was made for the normal Delphi guys since they are already used to the IDE. I much rather prefer to work with the Intraweb components inside the standard Delphi. TMS provides excellent extensions to the components and i do not have to change the language. So I re-use many many common routines between my normal Delphi and Intraweb applications.

    So I think Delphi gives PHP developers across the world tremendous benefit.

    I employed a few such developers and in just 2 weeks now have an entire web based application.

    So sometimes things are not perfect, just pragmatic.

  22. Look how long Prado has been around compared to VCL4PHP? I’m sure in time the VCL4PHP will be as good, if not better than Prado. Besides, coming from a delphi developer background I’ve always liked names with the letters VCL in them ;)

  23. @akash: I realize that my “most developers are not on windows” comment was a bit off. The IDE support under Windows has proven to be quite superior, but vendors like Zend are picking up with Zend Studio Eclipse, and NetBeans 6.5 introduced PHP support as well. When it comes to the VS.net vs Delphi approach that sounds right.. maybe I’m just not a Delphi-friendly person;)

    @andreas: I agree that Prado isn’t doing the best job out there, but having *something* is far better than having nothing. I state this because of the lack of name spaces in PHP and possible collisions with PHP classes. What would happen if PHP introduced a class with a name that VCL/PHP already use?
    @peter: There are lots of people wishing for the same.. who knows what’s coming? ;)

    @lami: I’ve not seen the demos, but I’d be happy to find something usable :) Vs.net is a far superior IDE imo.. pity that it does not support PHP.

    @delphi-php
    Yeah, it’s fairly fresh, but the team should have experience enough to create a solid architecture from scratch. Refactoring the code into something proper would take quite some time.

    @pieter
    I’d like to check out the latest version of VCL/PHP and perhaps do a follow up on the topic, and I will discuss the points you bring up in your comment.

  24. [...] 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 [...]

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">