Rails to Seaside – Some things I missed from Rails
I am a Junkie
I must first admit that I am a web framework junkie. While I don’t pay attention to most of them out there, I do stand up and take notice when one seems inventive, efficient, or fast. I would probably jump on board if there was one in C, just because I would be curious to see how fast it would go. Anyway, for the past few years, I have played with Django, Ruby on Rails, Seaside, and am currently messing with Lift.
In a previous article, I stated that i have traded in my Rails gun for Seaside. While this is pretty much true, it is not 100% true. Since there was a great deal of chatter about that article recently, I must qualify some of the comments I made.
Rails is great for a web SITE
The distinction I neglected to make was the distinction between a web SITE and a web APP. I know that I am touching on some serious flame war ground here, but I’ll go out on a limb here with the following definitions:
- Web Site – A site that is content driven. This would be a site where the content is the king. It could be news stories, sports scores, or celebrity gossip. In any case, the purpose of the site is to serve up content in a systematic fashion.
- Web Application – A site the serves to process data, and serve it up much the same way a desktop application would. It could be an online juke box, a ticketing/reservation system, etc. A system where processing and displaying user data is the key.
In all projects I work on, I hire a designer. My design skills are nil. To even attempt such a thing would be a disservice to all humanity. From the designer, I get a pile of HTML and CSS files.
In the case where I am working on a plain old web site, without serious bells and whistles, Rails still works great for me.
In the case where I am working on something more complex, where the data and its processing are king, Seaside still wins hands down.
The things I miss about Rails when Developing in Seaside
While I love Seaside, there are still things I really miss about Rails in either case. I think my real hope is that someone out there will read this, and say, “OH! You are doing it wrong! Here is how you should do this in Seaside.” In either case, here is my list.
Editing CSS files
Like I said, I get a pile of CSS and HTML files from a designer. At that point, I just throw them into the layouts directory, and start filling in the blanks. Inevitably, the design will take on a different look here and there. In Rails, I always set the designer up wit git, so s/he can change the css file at will, then deploy it as needed. This way, I am not involved in the process, and the designer can change it at will.
In the case of Seaside, there is much more setup involved in getting them a viable editing system. They have to edit the file in the smalltalk image, which adds many extra steps. Rather than being able to use their toolset to edit the css files, then just push them, they end up needing to cut, paste, and push their files into the image.
For the uninitiated, the look and feel of smalltalk is much different than anything they have seen. Designers are usually not tech people, and are oftentimes unnerved by working with smalltalk. There is usually much more training involved in getting them to use it efficiently.
I know it’s nit picky, but I know how much I hate when someone makes me add extra steps into my workflow, or change toolsets, and I like to avoid doing that to other people.
The documentation for Ruby on Rails has evolved massively over the past few years. Not only the official documentation, but the unofficial documentation in the form of blog posts. It’s rare that I run into a problem that is not a quick google search away.
Seaside has a little bit of work to go on this. Since the whole of the source code is only a few clicks away, it’s easy to find the code for the part in question, that seems to be the long way about it in alot of cases. Sometimes, you just want to get a set of changes to your project pushed and out the door.
Sometimes you want to build a clock, sometimes you just want to know what time it is.
Admin Interfaces and Scaffolding
One of the first things I do when putting together a site is to build an admin backend. I usually use Active Scaffold for this. This allows me to quickly set up an interface that the client can use to populate data while I work on the front end of the site.
In a good deal of cases, the backend needs little customization to make it a completely usable for the final product.
This is one thing i really wish I could do in Seaside.
User Authentication Management
While I have to admit that in Rails, user authentication is handled as a plugin, it is still there, and only a few clicks away. While I have only done this once in Seaside, it was still kind of a pain to have to cobble together a user authentication system.
Maybe I will see about wrapping up what I did (and am doing on my current project) into something I can publish.
Plethora of Gems
Before I start coding anything, I always search for a gem that has already done what I need. The search usually ends pretty quickly, and I install, and am on my way.
I know this is an unfair nitpick. I need to start publishing my own solutions to Seaside day to day tasks to alleviate this problem, but sometimes, I just need a hunk of code that I know works. It’s nice to be able to just plop that code in.
Looking back at that paragraph, I am going to start publishing my solutions, and be part of the solution, not the problem.
Routing and REST
There are a great deal of cases where URL matters. This seems to be up to fierce debate, but let’s all just pretend that URL does in fact matter. In Rails, it’s effortless to set up pretty URLs, resource based URLs, and the like.
Sometimes, I think of the routes.rb file as just a steering wheel for the site itself. No matter how I try to think about it, I love this functionality.
I think the problem with this thinking is that it is somehow tied to the idea of a content based system. These pretty URLs make it easy to make a grab at content, but are pretty useless in the process of manipulating data.
I am currently looking at the idea of using Pier as a wrapper for an application. I am trying out writing the controls and models as embedded controls, then using Pier to display the web application only when needed.
I think I am finding that Web Applications live in a space that is a little muddy. While they live to process and gather data, they must also be able to publish that data in a way that is easy for non technical users (and search engines) to index and gather.
Pier makes content management very easy, but for a site that is pure content, I find that it misses some things I can’t live without. If anyone is interested, I can expound on this in a new entry. In reality, I should really just ask about joining the Pier developers team and work on those issues.
In the murky world of Web Apps that must also display data in a pretty fashion, Seaside and Pier might be the answer. I will be looking into this and posting my findings soon.