Tuesday, February 13, 2007

Componentized Elements in Web Apps

OK. Say you've got a complex web app with lots of bits and pieces. Say it's for a company which has clients. Say further you want to create a client login which is a different view on the same data -- one where the client only sees their own data, and none of the company's internal data or of the data which belongs to other clients. So you round up a few bits and pieces, have them filter their output appropriately, and there you go.

If you're working in Rails, you put the same partials on a different page, and alter the find() calls to use with_scope. Worst case scenario, you might have to do a little refactoring. I had to do that today -- and in fact, I've got more refactoring to do. One of the pieces of code used a regular Rails template instead of a partial -- so I had to copy and paste. Another piece used a partial, but built the find into a class method on the model. So I had to write a new find from scratch. It wasn't hard, but it was kind of annoying. It could have been more elegant.

On the class method thing, you could probably call that a design flaw -- and a certain amount of this is just normal work. You can't automate everything; programming languages don't obviate the need for programmers. Nor can they make design errors impossible, and the more I learn about languages, the more it looks as if the worst languages all result from efforts to accomodate bad programmers instead of letting them sink or swim. So a certain amount of this, you just have to deal with it.

But the rest of it? Having to copy existing code because it's in a template, not in a partial? Not exactly DRY, is it? And ask yourself how you'd get around it, in Rails. The best you could do is move the code to a partial and then, in the situation where it's called as a regular template, write a wrapper template around it just so you can make it a partial in the first place. In other words, your options are redundant render() calls -- in the controller and the wrapper template -- or redundant template code.

It's funny, because I hate advocacy, and my Smalltalk-fu is appallingly weak, but this is the first time where I was doing something in Rails, I felt actively constrained by the framework, and I knew for a fact it was easier to do it right in Seaside. In Seaside all you do is write an object which generates the output. There is no difference between a partial and a complete page in Seaside. It doesn't matter. And this makes delivering the same output in a different context much easier. Seaside apps are componentized from the word go, so rearranging the components is easy.

It's funny also because most of the buzz about Seaside centers on its continuations, but the componentized paradigm might actually be a much bigger idea. There might actually be a way to reorient Rails to accomodate this paradigm. All you really need to do is extend render(). Move the partials out of the filesystem and into Ruby objects. The Rails model, where templates live on a disk, puts limits on the componentization your app can have, but if you keep the template system, but move the actual templates out of the filesystem and into the code, so that you can nest them arbitrarily without manually nesting render() calls, then you've got a big big part of what makes Seaside great.

Then again, you could just buck the trend and use Seaside.

Anyway, every time I post something like this somebody calls me a Seaside advocate, so I just want to reiterate, I write Rails for a living, I can barely do "Hello World" in Seaside. Language wars are a waste of time. It's the ideas in the languages that matter, not the languages themselves. (And the same is even truer for frameworks.)


  1. Hey Philippe -- I lurk on the Seaside list, I've seen that thread, although I'm still just getting the hang of Seaside. It does seem as if continuations are used a lot less than the hype would suggest, including my own hype (my screencasts and earlier posts). It also looks as if both continuations and decorators are used more within Magritte than in day-to-day coding of web apps. It's an interesting thread.

  2. This doesn't smell of advocacy at all to me. This is what happens when you allow yourself to open up to the possibilities of something truly different from what did and believed before. It changes your perspective on both the new thing _and_ the old thing. It makes you wonder how those specific areas of the old thing would look in light of your new experiences.

    I hope as the Rails community matures, more and more of us find our way to Seaside and other frameworks which provide a new experience. The quicker we start to see high level architectural limitations in Rails, the quicker Rails will improve. If nobody questions it, it'll eventually stagnate.


Note: Only a member of this blog may post a comment.