Rhtml in Ruby, Template Toolkit in Perl, Python’s Django templates, Java’s JSP or Freemarker, and ASP .Net files. All have the same philosophy – render HTML with data streamed from the corresponding web framework ‘controller’ modules.

It’s a great concept – lets you refactor View Templates and come up with ugly looking prototypes quickly. I say ugly since most enterprise programmers tend to have little or no web design skills. Learning effective UI Design is not trivial and asking your programmers to come up with slick UI is a lost cause.

Then you hire Graphic Designers and UI Developers. And your slick RHTML model starts to break horribly.  Web Designers’ tools such as DreamWeaver etc do not understand the server side Templating languages or they understand parts of it. The Web Developer has absolutely no interest in learning the weird syntax And it’s MUCH harder to design and test web pages in Dreamweaver with pages refactored in mutliple files!

When faced with the stalemate, we went back to basics. Separation of concerns!! Divide and Rule. Let two teams work with their favorite tools and we’ll connect the bridge with good old JSON transport. No need to do server side templating, rendering and refactoring. The backend developers had no need to mess around with HTML, CSS, Gifs and PNGs!

So, here’s our setup which keeps everyone happy. For now.

The only connection between Developers( including  Javascript developers) and designers is via <div> IDs. Once those container blocks are placed in HTML pages, the Programmer renders the UI widgets and takes care of AJAX communication with back end.

The Web Designers can continue using Dreamweaver and it’s associated parameterized templates to manage refactoring.

Going pure JSON also means, we can do away with massive rendering Engines in Rails, Merb or other frameworks and work with much simpler Data Delivery Engines which are REST compliant and serve pure JSON. We’ll talk about building such an Engine using Rack in a separate post.

Apparently, merb’s approach to sending email is far better than ActiveMailer. However, I still find it quite annoying and heavyweight for simple applications. And most of the email notifications sent from web applications tend to be simple. In order to send emails via Merb, you need to create mailer views and mailer controllers and pass parameters between them carefully. I, for sure, always get confused which parameters to pass where and how incoming parameters get be exposed to the mailer view templates.

Here’s a simple routine to send emails right from within your merb controllers. Or any other place, for that matter.

 
 gem install mailfactory
 gem install smtp_tls # if you need authentication or 
                            #want to use google smtp.
                            # A quick google search will find it.
# start sending emails:
require 'mailfactory'
require 'net/smtp'
mail             = MailFactory.new
   mail.from      = 'your@company.com'
   mail.subject  = 'Test'
   mail.html       = 'html mail body'
   mail.text       = "mail text , if it's not html"
   mail.replyTo   = 'noreply@company.com'
   # repeat next line for each attachment
   mail.attach_as(file_path, 'filename to attach as', 'application/pdf')
Net::SMTP.start(
  'smtp.host.com',
  25,
  'from@domain.com',
  'smtp username',
  'smtp password',
  'plain' # authentication method
) do |smtp|
smtp.send_message(mail.to_s, 'from@address.com', 'to@address.com')
end

I find this simpler since it’s encapsulated in one place. No need to create multiple files and impose entire MVC paradigm for sending emails. Let’s KISS.