In the distant past, “real” programmers had a healthy disrespect for drag-and-drop app dev products such as Visual Basic and Access. Command-line lovers turned up their noses at the products’ inflexibility: if someone decided that a piece of the user interface needed to be a pixel or two wider, the friendly frameworks would turn as mean and forbidding as the voicemail system at the DMV.
This attitude has been changing, and ActiveGrid’s new Application Builder and Server is a good indicator of where the wind is blowing. The guts of the project are hard-core, text-based open source workhorses, but they’re covered with a clean, crisp and very non-textual IDE (Integrated Development Environment).
The change may even be a bit shocking for programmers used to the old LAMP (Linux, Apache, MySQL, and PHP/Perl/Python) stack. ActiveGrid Application Builder looks like a normal IDE with a directory of files on the left and an editing panel on the right. There’s no need to debate between Emacs and vi anymore; in fact, you can throw away your text editing skills, because much of the editing is done visually.
I must confess that this kind of programming never appealed to me. Visual diagrams such as UML are 10 times harder for me to understand than ASCII text, but a number of programmers I respect for have turned to creating their code in visual systems. And after using ActiveGrid, I can say that its tools are quite good for what they are: A deliberately simple set of tools for crafting Web applications.
Getting visual
ActiveGrid stores most of the data in XML-based formats in text files, but you’re not allowed to touch them. Instead, you create your app by dragging around boxes that represent the data schema and the workflow. If you want to add a foreign key or mark some transition, you draw a line instead of creating a variable name and repeating it. There’s still an opportunity to use text editing to write some Python or Perl code, but that’s one of the few text-editing windows in ActiveGrid.
The product does lack an easy mechanism for tweaking the underlying XML. Many good IDEs offer tabs for switching between the picture and the words, but ActiveGrid does not — so you could spend hours searching for a bug.
ActiveGrid hides the XML because even the best programmer can mess it up with an errant tag. My guess is that ActiveGrid will add an XML-editing feature in the near future; it would be extremely useful for complex projects. Until then, as one ActiveGrid engineer pointed out, I could always fire up Emacs or vi if I needed it, and the XML is stored on disk.
Polishing the LAMP
I really like ActiveGrid’s one-button integration for creating and deploying apps. Too many LAMP projects begin with pages of instructions on downloading libraries, changing path names and reconfiguring conf files. With ActiveGrid, it really is possible to click a few buttons and let the wizards build up a full application with complete access to a database. Push a few more buttons, and it’s deployed and running on the server.
The system produced by these wizards links a few promising programming standards. For example, the business logic or workflow that governs what happens to the clicks and POSTs is specified with a BPEL (Business Process Execution Language) file. A Web form is written out in an XForm file; a request for data from a distant server is written out as a Web service (specifically, WSDL) file. The only place the ActiveGrid team didn’t use open standards was the XML layout file that controls how the XForms are converted into CSS and HTML files.
There are other strengths, too. The ActiveGrid deployment wizard will write out all of the necessary files to any Linux server running the ActiveGrid stack — MySQL and Apache with mod_perl, mod_python. The wizard also offers to deploy the app across a grid of computers with various degrees of support for persistent sessions — an enticing feature that I couldn’t test without a grid.
Dueling with a dinosaur
I’ve examined four versions of ActiveGrid during the past few months. Version 1.0 was rather raw and limited, but the development team has clearly been working hard, quickly and diligently. Version 1.2 fixed many of the rough spots with new features that make it simpler to customize the output version, and 1.5 continues that trend. Normally, I would not compare a new product such as ActiveGrid with a dreadnaught such as Java, but the CEO of ActiveGrid recently told Business Week that Java was a “dinosaur.” Alas, I wish that were so. Although it’s clear that some of Java’s deep complexity is a result of overly ambitious engineering, a misguided infatuation with XML and too many geniuses stirring the pot, a tool such as ActiveGrid can’t simply replace all of that with an uncomplicated design.
And during the several months I’ve followed the tool, the company has already added some flexibility and Java-like complexity by opening up more of the interface. Earlier versions wouldn’t let you edit the layout files that controlled the way XForms were turned into HTML; in 1.5, you can actually change the XML. ActiveGrid will appeal most to people who like dynamically linked languages.
Right now, ActiveGrid Application Builder and Server is good for spinning up sites for clients who aren’t too picky about the design. Its structure is solid, and as clean ways to expose its hidden features are found, I think ActiveGrid will be a serious competitor.
QuickLink 061067
