revjim.net

I've been playing with BinaryCloud quite a bit over the past few days. Thanks to one of that project's key developers, Jason, I've gotten pretty far. I can't say I'm an expert in all things BinaryCloud. Not by any means. But, I'd like to offer my first impressions. Please keep in mind that my first impressions may not be accurate, as I have yet to fully understand how everything within BinaryCloud functions.

First of all, I'd like to state that I think this project is populated with some of the most advanced PHP developers I've met to date. The structure of the code, and the thought put into how it works is highly advanced. It's refreshing to know that such developers exist in the PHP world. I've known that such developers must exist, or all of the new features in PHP5 wouldn't have ever been asked for, let alone considered and implemented. However, before now, I had never met any of them.

BinaryCloud is a great framework. Completely object oriented, it takes a child/parent approach to page development. What this means, essentially, is that components, known as Nodes, can be integrated into a single page which promotes code reuse and simplicity in design. Imagine, for a second, your corporate website. The front page, despite what's on it, almost always has some form of BreadCrumbs (the display widget that tells you where in the site you are) and also some form of Navigation (the display widget that tells you where you can go from here). In most cases, for every application that exists, these widgets are reimplemented because users desire to see them. With BinaryCloud, this type of thing becomes a breeze. First, you make your FrontPage object. It does… well… whatever you want the front page of the site to do. Then, in the definition of that node, you add two children, a BreadCrumbs object and a SideBarNavigation object, for instance. Through some hefty recursion, each of these children are built and rendered according to their own templates and made available to the template of the FrontPage. I think that it's instantly obvious what kind of power and flexibility this affords the developer.

Couple that core functionality with an outstanding set of support libraries, a Storage abstraction and Authentication feature (both which I have yet to explore) and you find yourself with a very feature rich framework that forces separation of code and layout (and layout logic) and provides the developer with a straightforward method for simple code reuse and flexibility.

Despite all this, I think there are some things holding BinaryCloud back. The first of which is the method with which Nodes are defined. With BinaryCloud, in order to define a node, its children and propertys, you must create an NDF or Node Definition File(?). This NDF is straightforward and is in XML, which I think is a great choice. Unfortunately, BinaryCloud doesn't actually read NDF. Instead, it relys on its build tool, Phing, to compile this NDF into native PHP code when the application is built (or "Phung" as it is known). Because of this reliance on Phing, when writing a BinaryCloud application, you have only three choices: 1) write the PHP code by hand, which can be cumbersome, 2) author an NDF and use Phing as your build tool, or 3) author an NDF and compile the NDF to PHP manually. This is a problem. First of all, if authoring the PHP code by hand were as straightforward as it sounds, there would be no need for the NDF to begin with. It's not. And having to either use Phing or compile the NDF manually in order to deploy code is less than desirable. I like Phing. I think it's a great package. But, just as in the "C" world, simply because my library is built using "make", that doesn't mean I also have to use make to build my application that uses this library.

BinaryCloud also relys on Phing to handle internationalization. This practice seems a bit weird in use. What happens, as best as I can tell, is that, for each language you choose for your app to support, Phing does String Replacement (using some classes from BC) to create different versions of BC for each language that is desired. However, this doesn't seem to be the way it should be. BinaryCloud should be capable of handling internationalization from within itself without the need for a different version of itself for each language.

With this being said, I think that BinaryCloud would benefit greatly with the following changes:

BinaryCloud requires NDF. Therefore BinaryCloud should read NDF.. The developers claim that they found that compiling the NDF at runtime was too expensive and required too much time. And I'm sure I would agree with them. However, there are other methods. Consider how Smarty handles compiling its template files. The first thing it does it look to see if it's been compiled already. If not, it compiles the template and caches the compiled version. If it has, it checks the timestamp on the compiled version and compares it to the timestamp on the non-compiled version. If the non-compiled version is newer, it recompiles and recaches. Additionally, in order to save that "stat" call required to check the modification time on the non-compiled version, you can tell Smarty to run in a mode that only compiles a template if it hasn't been compiled already, and it doesn't check the modification time of the source file. It seems that if BinaryCloud adopted this concept for handling NDF, execution time would only really increase in the event that the source file had been modified.

BinaryCloud requires applications written in it to use its build tool. This defeats the live editing that PHP developers know and love. PHP has its strengths and weaknesses. Its weaknesses should be corrected. Its strengths should be praised and exploited at every opportunity. Being able to edit live code without the need to compile is one of these strong points. While I like Phing and what it is capable of, I should not be required to use it. Additionally, despite whether I use it or not, I should not lose my ability to edit code live and package later. BinaryCloud should have a Phing target called "library-only". By calling Phing with this target, BinaryCloud would be installed into a common location, properly configured, and ready for inclusion from any PHP page despite the build tool, if any, that was used to get it there.

BinaryCloud uses Phing to handle internationalization. This should be a feature of BinaryCloud that doesn't require Phing to operate correctly. Phing is simply using String Replacement to handle this task. And, for the most part, it is only used for Exception messages. If the translation were handled dynamically in the Exception routines, this requirement would be removed and the system would become more flexible. Sure, this means the exception routine will take a bit longer to complete (as it will have to perform translation), but… this is an exception… not the rule. Therefore, if a few extra seconds are spent handling this whenever there happens to be an exception, that shouldn't be a problem. However, this does mean that in one case, and in one case only, an Exception message might be displayed in a "default" language. In the event that an Exception is generated and a translation cannot be found for it, a "CannotFindTranslation" exception should be generated. If THAT exception cannot find a translation, and ONLY then, that message will have to appear in a default hardcoded language. However, this same thing would have occured with the Phing build process. The only difference would have been that it would be Phing generating the error and not a run-time exception from within the app.

I think that, with these modifications, BinaryCloud will be easier to understand by new developers, and more flexible in the long run. As always, I'd love to hear comments, corrections, or new suggestions. And of course, since I really don't know much about BinaryCloud, if any of this information is inaccurate, please let me know.