Magic Usually Falls Short

Last Thursday I was given the okay to write a company bug tracker.  It was pretty clear that we needed a tracker, but I never got the okay to do it.   I've been playing with the idea of using SubSonic, but my other project is sitting at 85% completion and I didn't want to introduce new technology until it was delivered.  Now was the perfect opportunity to use a rapid development tool to build a new bug tracker.  As of today, it's functional.  Users can file bugs, read bugs, upload files, assign bugs, etc.  All in the span of about 14 hours of development.

SubSonic accounts for a lot of the speed in development.  Since I wasn't worried about SQL or SPROCs or database side stuff, I could focus solely on the business logic and HTML.  (I must admit that about two hours were spent tweaking stylesheets; I'm a horrid designer.)  The project got up fast and I only used the generate command of SubSonic.  No Scaffolds or ManyMany lists or Sugar module.  To be honest, I didn't deal with the scaffolds until the last hour.  I was simply amazed by what they could accomplish in such little code.  I had been writing the CRUD pages for my tables, but after I learned of this super-easy method and how well it worked, I deleted my pages and replace them all with Scaffolds.

Huge mistake.  (Like, revert huge.)  One of the pages I was deleting was one for editing a basic Users table.  You know, name, email, address, social security number; the usual.  The scaffold worked beautifully for everything in the database.  The problem was that the DB table was synced with the ASP.NET SqlMembershipProvider to do security.  Whenever a user is added to the system, they get added to the aspnet_Users table by calling Membership.CreateUser(user, password).  Right after that, a row is created in the SiteUser table that stores all of the extra user information that we need.  They are joined on the user's username.  The scaffold doesn't know this, nor does it care.  I was screwed.

By using the scaffold in this situation, I was eliminating some necessary behavior in my application.  Sure I dropped the code size by more then 150 lines.  But the new stuff didn't include the one line I really needed.  Whenever you use RAD tools, you usually lose the ability to fine tune.

The same holds true for using a DataGrid vs. a Repeater.  The DataGrid does a lot of things magically.  I was amazed that it could just auto-generate columns and throw the entire table up onto the web page.  After the initial "whooosh" of the magic hitting my eyes at 80mph, I realized that the table wasn't easily customized and wasn't that flexible.  I ended up using <asp:TemplateColumn/> for almost every column.  Since I was essentially the code inside each table cell, the only thing I gained was not having to deal with the <tr><td> elements.  This is still an advantage, kind of.  But having all of my data was buried under <td>s and <div>s, it was incredibly hard to style via CSS.  I lost a an hour just trying to figure out how to make the <td> elements have a border.

I know it's naive to expect a new tool or technology to magically fix your problems.  No silver bullets and all that jazz.  When C# and Java came out, it was fantastic because we no longer had to deal with memory management.  I think this is a good thing; programmers shouldn't be messing around with memory.  With things like Rails and certain aspects of SubSonic, it prevents the programmers from overriding certain methods and styles.  When you move up the ladder of abstraction, make sure you don't abstract away control you might need.  If you do, you will only solve some problems to create new ones.

10 September 2007: Grammar and style edits.

Print | posted on Wednesday, September 05, 2007 12:15 AM

Feedback

# re: Magic Usually Falls Short

left by Rob Conery at 9/6/2007 2:15 PM Gravatar
"Whenever you use RAD tools, you usually lose the ability to fine tune." SubSonic's not a RAD toolset - it's a utility that's there for you to use. In the same way that you don't want to put your thumb under the blunt end of a hammer, you probably will want to evaluate what the tool does before hanging your hat on it.

In this case - yah the Scaffold doesn't know about data replication. It does care - I'm sure it loves you very much. I might love you too if I knew you. But the scaffold can only do so much for you friend :).

In this case I might offer that you can use the PostBack to your advantage. Check and see what's happening on the postback, and if you should synch the data.

Moreover, since you mention that you don't mind doing data-side stuff, a trigger might be the perfect option (though some people hate triggers - I love em).

Finally - I think there should be an eventing model here that we should add to the scaffold. Something like "OnInsert", "OnUpdate", and "OnDelete". I'm up to the teeth in rounding out other fun things and could use your help... you game?

# re: Magic Usually Falls Short

left by David Sokol at 9/10/2007 5:20 PM Gravatar
The event idea would work nicely. I'm not exactly sure how to structure the event stuff, but I'll poke into the SubSonic code tonight. I can't guarantee any sort of quality, but I can give it a shot.

As for SubSonic not being a RAD toolset: I guess it depends on what your definition of RAD is. SubSonic cut out a very large portion of my dev time. To me, that's enough to call it a RAD tool.
Title  
Name
Email (never displayed)
Url
Comments   
Please add 2 and 2 and type the answer here: