Zend_Tool - Other Framework Homework

Symfony

Screenshots

Installation via the PEAR channel was simple and it give you a system wide interface into creating Symfony based projects.

The help system is in its expected place... And as a side note, all utilities for "tooling" run through this installed "symfony" command line. The interface while good, is a little unintuitive. The groupings of commands and their actions is limited. One NICE thing is that there is the concept of a task name namespace. This is useful for logical grouping of tasks.

Another nice aspect of this is the ANSI color coding, it visually breaks the screen up into easier to see "chunks".

The actions by default are very verbose, as you can see below every filesystem action is logged to the screen whether its for file/directory creation or chmoding. Also note the use of columns and ANSI colors.

I setup both my hosts and Vhost so that the newly created app could be served via my local apache instance.

Originally, nothing came up. The default project doesnt have an index.php file.

Creating an "app", which is similar in nature to a ZF "module" created an index.php file. This file actually came up with broken images.

Upon further investigation, I found i needed an alias to the system wide public files shipped with symfony. This is good and bad. (....)

The working front page of the symfony project I setup.

Propel is the ORM that is "default" (although there are other options available.) Propel uses YAML to describe the ORM data model. This YAML file is a metafile that will then be used to both generate code as well as generate the db tables.

Building models actually means taking the metafile and generating a new xml based metafile. Thats a lot of artifacts isnt it?

Configuring the projects database connectivity.

There is actually a mismatch in the versions of Symfony and PropelPDO and what it expects
as a connection string. This problem is not resolved yet which means you have to edit the files by hand. Connection settings are written into the database.yml file.

One must run the sql build task in order to generate the SQL necessary for the project.

Screenshot of the generated SQL code.

(reconfiguring b/c of bug mentioned above)

The new database file edited.

Building, and executing the SQL. REALLY nice use of ANSI blocking to show the user the status of an operation.

Building Forms.

Forms are quite simple

Generated code for a "CRUD action".

A generated html form.

Summary

This framework has the best "framework" feel. Installation was easy using the PHP package manager PEAR (leveraging the PHP ecosystem). From a tooling standpoint, its the most advanced and fluent (even over rails). The ANSI colors give it a polished feel, even though the command line structure is less than ideal. The verbosity of output gives a great feel of transparency in all that its doing.

Symfony creates a nice (read: pretty), default project screen. It also gives you access to developer tools, (loggers, consoles, etc).

The downside is that symfony is packaging several technologies that are not under the same umbrella. This gives a less than intuitive API across the board, as well as having to understand different versions of technolgies within a single version of symfony itself.

Another downside is that there is an extensive use of metafiles and config files for generating scaffolds & CRUD artifacts.

CakePHP

Screenshots

The console window with no options

Making the environment. This is essentially b/c cakephp is a download and go type of setup. There is no pear installer.

The full "bake" all. Baking is the term the cake project uses to "do something"

The Database settings that were generated from the command line.

After creating a table, you can run bake model and it will introspect the database. It will attempt to find table names and create models based off them. It expects tables to be plural.

The generated Controller.

The base model.

The ctp is the cake tempalate file. This one is the actual form. As you can see it utilizes view helpers to generate the views.

The generated edit form.

This is the generated index or listing view script.

The generated view view script.

This a screenshot of the page (with debugging on as you can see in the bottom).

Html view of the add form.

HTML view of the edit form.

Summary

Install doesnt use PEAR, must download and go. There is a "cake script" in the scripts/ directory, and the expectation for usage is to put it in your PATH.

The console script itself is kinda clunky. The argument ordering is less than intuitive and they are using framework specific terminology - for example "cake bake ....".

The Scaffolding itself is decent, although its fairly opinionated. It expects the db tables to have pluralized names. That said, it does a decent job of doing the existing dbtable -> code generation. The generated code is very verbose, which makes it easy to customize individual actions later on down the line.

Cake also comes decent UI for scaffolding as well as a "Development mode" which will show all of the queries used to build a page. This is similar to Rail's server console window, and symfony's developer "toolbar".

RubyOnRails

Installed via GEMS, the Ruby package manager.

The rails help menu.

The verbosity of creating a new project

The default screen for a newly created project

Editing the database.yml file by hand to add our projects database connectivity

(I actually had to recreate a project b/c your database needs to be configured in the same line as the project creation.)

For some command you switch over to rake to execute. For example, this one does the creation of the database if its needed

Creating a Home Controller and index action

The generated view script

Rails comes with a small web server to run your project out of during development. The idea that this is also the logging mechanism is kinda cool. This will show you all of the dispatch and sql information as the page is generated.

Scaffolding. This is the creation of a CRUD based controller, model and associated views for creating a quick and dirty CRUD functionality and data model

A log of the utilization of the CRUD controller from the server running within rails

(this should be moved above, but this is a longer listing of the steps to do CRUD scaffolding from the command line)

This is an HTML view of the generated CRUD

Summary

While there is no doubt that RoR is popular, it suprises me that there is not a more fluent interface for the "tooling" that comes with it. There are 3 main ways of executing a command, which leaves the uninitiated user with a lot of documentation and tutorial needs. These commands are rails, rake and script/generate.

The framework is especially verbose and offers a ton of transparency. Also, the built in server is nice when used as a logging window for development.

Scaffolding generates lots of customizable code, even though its very verbose when doing it from the command line: "script/generate scaffold Paste username:string ..."

Django

Screenshots

Django is installed by downloading the tar ball and executing the setup script. It will copy the necessary libraires into the system django setup.

At this point, you can start a "project". Projects are actually django namespaced packages. This has some unfortunate side effects, particularly with naming.

Not alot of files are created. In fact, Django is not a true MVC framework.

Database file for connectivity must be edited by hand.

Upon "syncing" the database, it asks to create an "Authetication and Autorization" system.

The product of the setup of the auth stuff.

Creating an "app" within a project. Similar to ZF's creating a module inside an application.

Must add the "app" to the main settings.py to be loaded by the project when the python web server starts up.

The generated SQL

Models in django are created via the command line, and the stucture must be defined inside of the model itself. The command line tools will then read the model and create the appropriate database.

Running the database generation script.

The new table 'pastebin_paste'

Adding the built-in admin interface for the project.

The login screen (this utilizes the auth system setup previously).

The main admin screen. As you can see its a full admin for managing authentication and authorization types of information.

After adding the admin to the project, and adding admin capabilities to the pastebin "app", it can now be administered through the built-in admin.

Listing uses the auto string casting.

Defining the string casting method to be used in the built-in admin.

The running of the web server handling this project.

Summary

Out the box, the interface is not very intuitive. Also, the structure is less than ideal. A "project" is a python "module", and as such, contains the same structure as a library component. Also, Django is not MVC. It looks and feels like a custom or home grown framework, similar to the numerous frameworks in PHP during the 2001-2005 timeframe.

Again, there are multiple commands the user must know: django-admin.py as well as python manage.py xxx. This also leaves the developer with a less than intuitive experience.

The highlights of django are that for basic crud projects (the 90% projects), it gives you both an admin interface to the tables you've created (which by the way is Model -> dbtable creation), as well as installs a pretty extensive authentication and authorization system.

Django also comes with a simple web server to run your project which also will show any exceptions thrown from a bad request. ALso, since its Model -> Database generation, this leaves you with a pretty rigid db structure that probably cannot be changed easily since its tied so closely to the model.

On the plus sides, the admin is very nice and it does give you some common structure to work with when you are into python based web development.

Feature chart

Framework	Installation Mode	Project/Application Creation	Application Module Creation	Controller View Generation	Model Generation	Metadata -> Model&Table	Table -> Model Gen	Model -> Table Gen	CRUD Admin	Cli Help System	Embedded Web Server	Logging Console	Library Freezing	Welcome Screen after Project Creation	Config VS. Convention
Symfony	PHP's PEAR	Y	Y ("App")	Y	Y ("Module")	Y (Propel)	N	N	Y	Y	N	Y - help bar	Y	Y	Convention before Config
Cake	Download & Drop	Y	Y ("plugins")	Y	Y	N	Y	N	Y	Y	N	Y	N	Y	Convention
Rails	Ruby's Gems	Y	Y ("components")	Y	Y	Y	N	N	Y	Y (limited)	Y	Y (via web proc)	Y	Y	Convention
Django	Download & setup.py	Y	Y ("App")	N	Y (empty)	N	N	Y	Y	N	Y	Y (via web proc)	N	N	None