dotEvan

There’s a debate going on here regarding Smarty‘s usefulness as a developer tool. It was sparked (again) by the launch (or at least newly noticed) nosmarty.net. I commented:

I don’t understand how ZF or Symfony or any framework can be an “alternative” for Smarty. Smarty is not a framework — it is simply a templating engine. It should not be used as anything other than a component of the view layer of your MVC application. Just like any other software, it has a learning curve and a certain amount of quirks. Using Smarty does not guarantee good design — that still needs to be handled by programmers who have more experience than writing a “Hello, World!” program and reading a tutorial.

I think the fact that it’s been around since 2001 and is still in use is a testament to it’s usefulness within the community. If Smarty is used in the right manner, I don’t see why it can’t have it’s place within the arsenal of tools for developers to use.

It was countered by Paul M. Jones with:

In my opinion (note the small “o”) there *is* no right manner in which to use Smarty. It is the solution to a mis-stated problem. I suppose I shall have to expound on that at greater length in another blog post. Oh, I already have! http://paul-m-jones.com/?p=273

I understand this point, however I still have one reason to use Smarty: PHP is an ugly templating language. I’ve used Smarty and Symfony (which relies on PHP’s alternative syntax for templating) and I still prefer Smarty.

The examples on nosmarty.net generally site one instance of echoing a variable. In this small case, sure, I can see — why use a heavier templating system that takes longer to parse and can be a bitch to configure and deal with. However, if you’re looking at a portion of a html page that has to output multiple variables, Smarty is much easier on the eyes.

SMARTY:
<td>Name</td><td>{$name}</td>
<td>Email</td><td>{$email}</td>
<td>Phone</td><td>{$phone}</td>

PHP:
<td>Name</td><td><?php echo $name; ?></td>
<td>Email</td><td><?php echo $email; ?></td>
<td>Phone</td><td><?php echo $phone; ?></td>

When you start repeating <?php … ?> everywhere it gets fairly redundant, and, frankly, ugly.

Perhaps my use case for Smarty is a bit selfish, but, ultimately, programming style and comfort boils down to personal preference. Most, if not all, programming tools have the ability to be misused. I still consider Smarty to be a useful tool in my development arsenal. Though I have not used smarty in over 2 years now, using strictly PHP templating (mainly due to Symfony’s templating conventions), I would happily start using it again to regain readable templates.

Subversion externals are a way to include other packages in your code that are maintained somewhere else.  For example, if I was developing an application that needed to send out mail, I could use SwiftMailer and define that as an external for my project. When I run ”svn up” it will grab files from the SwiftMailer project and copy them locally. (How to define externals is beyond the scope of this post. RTFM!)

One annoying part of externals is that even if there are no changes to your code, your Subversion status output will be filled with externals information. For example, I have included symfony as an external in my project and now the default status output is:

X      lib/symfony

Performing status on external item at 'lib/symfony'
X      lib/symfony/doc
X      lib/symfony/lib/plugins/sfDoctrinePlugin
X      lib/symfony/lib/plugins/sfPropelPlugin
X      lib/symfony/lib/vendor/lime

Performing status on external item at 'lib/symfony/lib/plugins/sfPropelPlugin'
X      lib/symfony/lib/plugins/sfPropelPlugin/lib/vendor/propel
X      lib/symfony/lib/plugins/sfPropelPlugin/lib/vendor/phing
X      lib/symfony/lib/plugins/sfPropelPlugin/lib/vendor/propel-generator

Performing status on external item at 'lib/symfony/lib/plugins/sfPropelPlugin/lib/vendor/phing'

Performing status on external item at 'lib/symfony/lib/plugins/sfPropelPlugin/lib/vendor/propel'

Performing status on external item at 'lib/symfony/lib/plugins/sfPropelPlugin/lib/vendor/propel-generator'

Performing status on external item at 'lib/symfony/lib/plugins/sfDoctrinePlugin'
X      lib/symfony/lib/plugins/sfDoctrinePlugin/i18n
X      lib/symfony/lib/plugins/sfDoctrinePlugin/web
X      lib/symfony/lib/plugins/sfDoctrinePlugin/lib/doctrine

Performing status on external item at 'lib/symfony/lib/plugins/sfDoctrinePlugin/i18n'

Performing status on external item at 'lib/symfony/lib/plugins/sfDoctrinePlugin/web'

Performing status on external item at 'lib/symfony/lib/plugins/sfDoctrinePlugin/lib/doctrine'

Performing status on external item at 'lib/symfony/doc'

Performing status on external item at 'lib/symfony/lib/vendor/lime'

This is obviously annoying as it obfuscates the part of the project that I’m working on. The switch command does have an option to ignore externals, aptly called –ignore-externals but I don’t want to have to type that in every time I run a svn st command.

After browsing around the net for a bit, I found this piece of bash script that will swap the defaults for me:

svn() {
        case "$1" in
                st|stat|status)
                        svnargs1=""
                        svnargs2="--ignore-externals"
                        for i in $@; do
                                if [ "--examine-externals" == "$i" ]; then
                                        svnargs2=""
                                else
                                        svnargs1="$svnargs1 $i"
                                fi
                        done
                        command svn $svnargs1 $svnargs2
                        ;;
                *)
                        command svn "$@"
                        ;;
        esac
}

What’s nice about this script is that I can run status on the externals as well by specifying –examine-externals — and they’ll be back, in all their annoying (yet sometimes needed) glory.

On my Mac, I just placed the code in /etc/bashrc and now it’s available as a layer over the svn binary. (You may need to restart your terminal session for it to take effect.)

I’ve been playing with the symfony auto-generated forms, which are a really nice way to bootstrap an application. However, the forms that it generates are not styled at all, which makes developing with it (and looking at it all the time) quite painful on the eyes. Here’s some CSS to make your auto-gen tables look more like what the forms book shows in the examples. All you’d need to do is class the table with “autoform”.

table.autoform {
	border: solid 1px #CCC;
	border-collapse: collapse;
	border-spacing: 0px;
	padding: 0px;
	margin: 0px;
	border-spacing: 0px;
}

table.autoform th,table.autoform td {
	border: solid 1px #CCC;
	border-collapse: collapse;
	border-spacing: 0px;
	padding: 3px;
	margin: 0px;
}

table.autoform th {
	background: #EEE;
	font-weight: bold;
	text-align: left;
	padding-left: 10px;
	padding-right: 20px;
}

table.autoform ul.error_list {
	color: red;
	padding-left: 20px;
	margin: 0px;
}

Zend Studio for Eclipse has finally arrived! I’ve been waiting for this upgrade for years. Zend Studio, in its previous incarnation, was certainly no slouch of a product. I’ve been using it since version 4. Aside from various Java platform issues, their product was extremely stable and increased my productivity over using other less featured editors.

My experience with Eclipse began in college while taking advanced programming courses in Java. It was an amazing product back then, and has only grown better since. However, the marriage of Zend Studio to Eclipse has proven to be a bit of a disappointment. Perhaps it is because I’m too used to the way that Studio 5.5 works and need to shift my IDE paradigm back to Eclipse. Maybe it’s the difference in how the system is configured by the preferences. Either way, it will take a bit of time to get used to and that’s just not something that I can afford at my job right now. Using Studio for Eclipse will have to be a weekend project to slowly ween myself off of 5.5 and learn how to manipulate Eclipse to assist, rather than hinder, my development.

One of the major pieces of integration that I’m interested in the new version of Studio is how well it handles remote files. My current development process requires that I use ssh/sftp to open and save files to a remote file system. In Zend Studio Neon (their beta version of the Eclipse integration, as well as in Eclipse in general), remote filesystem access was still a bit lacking and buggy. At first glance, it seems as if they have figured this out in Studio for Eclipse. However, I’m running into issues building the workspace through the remote filesystem. It’s slow and bogs down the Java process so I can’t develop while it’s building. I tried, heaven help me, to stop the build process, which locked up Studio, and now I can’t seem to open Zend Studio for Eclipse at all.

As for right now, I’m going to uninstall it and try re-installing over the weekend and playing around a bit more. They may call it Studio 6.0.0 — however, I think I need to treat this as a 1.0 release. Overall, I don’t think this release will be stable enough for me to use until a few more rounds of bug fixes, but I certainly like the direction that the platform is heading.