Archive for the ‘auto-generated code’ Category

The Context object in Symfony can cause hassles

Monday, August 24th, 2009

This summer I worked on a project where some other programmer had used the Context object in the model classes. This caused ridiculous problems. For instance, to run the command line tools (such as “symfony propel:build-model”) I had to hard-code the loading of a context object into the core classes – what an ugly hack!

So I was intrigued to read of the problems that the Context object can cause in your form classes, and how dependency injection gives us an easy way to avoid needing the Context object.

You might read that and think “woah, this is getting complicated!” but we’re not talking about dependency injection containers here, we’re simply saying that you can make your form object depend on something to run. The thing it depends on should not be the context singleton, it should be the minimum thing that the form needs to operate correctly – which in this case, is a user object that supports credentials.

…The test here is where we are making this form “dependent” on a user object. In this case we are insisting that the object is an instance of sfUser, which you may argue is tying us in to symfony again, but you could use any test here to ensure that the object will have the necessary functionality you need, maybe check for the existence of a “hasCredential()” method for example.

When writing a test for this form class, we now only need to instantiate a user object and load it with some credentials – much easier than doing the same thing and locking into a context singleton. There may be other times when this form could be useful in a lightweight environment, where you can get speedy access to a user object but don’t want the overhead of the symfony context – you might not think of one now, but it’s best to code this way and you’ll have less reasons to kick yourself further down the line.

The goals of alternative scaffolding systems

Sunday, March 1st, 2009

I am dissatisfied with the HTML that is auto-generated by the built-in scaffolding system of Symfony.  I am planning to write a plugin that will generate HTML more to my liking. I know that, in the world of Ruby On Rails, there are several plugins that improve upon the built-in scaffolding system of that framework. Since these plugins have a longer history, and are more advanced, than anything in the world of Symfony, I am looking to them for some inspiration.

This is what Hobo says about itself:

It turns out that the hard part is not going fast, but staying flexible. This is where we think Hobo really shines. If you’ve played with “app builders” before, you’ll know about The Wall. The Wall is the point you reach where you have to give up and do it the old way because that one feature you really need just isn’t going to happen. Hobo doesn’t have one.

…Like Rails itself, Hobo encapsulates a number of opinions about web application development. The opinion that is most central to Hobo is this: we have found that there is a great deal of similarity from one web application to the next. Much more similarity in fact, than is supported by today’s frameworks. We would rather implement this stuff once.

Of course this approach is common to all frameworks—everything that Rails provides is there because many or all web applications will need it: database connectivity, session management, working with HTTP, etc. etc. The difference with Hobo is that we are trying to take this idea to a much higher level than is normally expected from a web framework. The ultimate goal is: don’t program your application, just declare it.

This is what ActiveScaffold says about itself:

Most web applications have many more model objects exposed on the backend, or admin side, than they do on the front. Coding interfaces for all those models is redundant and a waste of resources when all you need is CRUD functionality that’s smart enough to handle all your ActiveRecord associations.

Enter the ActiveScaffold plugin:

  • An AJAXified table interface for creating, updating, and deleting objects
  • Automatic handling of ActiveRecord associations
  • Sorting, Search and Pagination
  • Graceful JavaScript degradation
  • RESTful API support (XML/YAML/JSON) baked in
  • Sexy CSS styling and theming support
  • More extension points than you can shake a stick at
  • Guaranteed to work on Firefox 1+, IE 6+ and Safari 2+
  • Released under the MIT License, the same one as Rails itself, so you can use it freely in your commercial applications.

This is what Streamlined says about itself:

Streamlined is a plugin for Ruby on Rails that provides an instant, production-ready UI for your ActiveRecord models. It started as a way to generate Administrative back-ends, but has become more general purpose and flexible over time. Streamlined aims to bring the declarative goodness of ActiveRecord to the view tier. It manages the presentation, creation, and editing of model instances, providing full-featured scaffolds equipped with everything you need to quickly and easily develop a rich user interface for interacting with your data, including:

  • Zero-configuration relationship management
  • Ajax-powered widgets and transitions
  • Live data filtering
  • Out-of-the-box sortable lists and pagination
  • Exporting to XML, CSV, and JSON
  • Declarative and easily-customizable UI development
  • Cross-browser support including Firefox, Internet Explorer, and Safari
  • Pluggable CSS styling

This gives a sense of the possibilities.

Hobo has an especially interesting goal, to create a framework that is declarative, rather than imperative.

In the short term, my goals for a new scaffolding system are simple:

1.) The HTML should use divs and CSS rather than tables.

2.) Pagination should be included by default.

3.) An administrative dashboard should be created by default.

I know I will want these 3 things from every Symfony project I start, so, for me at least, it makes sense to have  a plugin that automates all this.