Entries Tagged 'General' ↓

Working with jQuery, it is common to find yourself needing some kind of templating solution. There are plenty out there, however sometimes the use-case is simple enough that you don’t really need a fully blow templating plugin.

We’ll take a task list as an example (just to be original). Lets say you have the following task objects in an array:

var tasks = [
  { id: 1, name: 'A todo item' },
  { id: 2, name: 'Another todo' }
];

Now you want to display them in an unordered list with checkboxes etc. What I like to do is create a ‘templates’ object, which contains my basic templates:

var templates = {
  taskList: $('<ul class="task-list">'),
  taskItem: $('<li><input type="checkbox" /> <span /></li>')
}

With these templates in place, it’s a simple case of cloning them when required and inserting the relevant data. jQuery’s ‘text‘ and ‘attr‘ methods are ideal for this as they handle the escaping of html entities. Based on this we can iterate over our tasks array and insert the relevant items in the dom:

var list = templates.taskList.clone();
$.each(tasks, function() {
  templates.taskItem.clone()
    .attr('id', this.id)
    .find('span').text(this.name).end();
  list.append();
});
 
$('body').append(list);

And that’s it, by using jQuery’s ‘text‘ and ‘attr‘ functions, you have complete control over your templates, without having to remember to escaping html. Your templates can be stored away in an external javascript file and everyone’s happy.

Just two days after announcing Ramble, Pete Otaqui has done a large refractor of the core code. Ramble, as a result is far more modular allowing for different output classes etc.

Now that we have a more solid API, we can concentrate on testing and porting additional Cucumber functionality. Many thanks to Pete!

Get the latest code from GitHub:

http://github.com/soniciq/ramble

I’ve been using Ruby on Rails at SonicIQ since the early Rails betas and have worked exclusively with Ruby frameworks ever since. Over the past few years I’ve seen Rails evolve, which has been a painful process in some cases as it has found direction, making the odd mistake along the way.

I have been working on a new project, getting a proper chance to use the Rails 3 beta and wow! …Rails just grew up.

With the introduction of Bundler, the gem dependency pain has disappeared. ActiveRecord’s API feels solid with the introduction of ActiveRelation. The new routing API (with the introduction of ActionDispatch) is amazingly concise, my routes never looked so good. The close integration with Rack enabling the mounting of other rack applications in a Rails app is just too easy… I could go on…

I think a great deal of the modularity and general solidness comes from the Merb merger, so big thanks to the Merb guys. I have felt none of the pain that I had in the past when needing to use anything other than the defaults, or hooking into the framework itself.

What more can I say, I’m in love with Rails all over again and so glad I stuck with it.

Thanks to everyone involved.

I’ve been debating over the past week whether or not to use SproutCore for a large application I am working on. What follows are my initial thoughts on the framework, likes and dislikes.

A fight with what’s right

Right, I’m afraid I’m going to start with a negative in the hope that I can focus more on the positives for the rest of the post.

I have been an advocate of Web Standards in the running on SonicIQ over the past 10 years, with this has come the adoption of Progressive Enhancement using Unobtrusive Javascript. Now along come two cutting edge frameworks, SproutCore and Cappuccino who completely abandon this culture in search of a desktop-like feel to web apps.

Having been an early adopter of techniques like Unobtrusive Javascript and seeing the benefits they offer, I am reluctant to give the finger to those without Javascript, even if this is now a small minority. With the advent of HTML5 I suppose this becomes less of an issue as Javascript is one of the many standards under the whole HTML5 umbrella and is just expected to exist. I can’t help feeling a little dirty though having a page of just script tags.

Am I being too “precious” about Graceful Degradation, or is this still relevant with the arrival of HTML5?

Fat Client

Both SproutCore and Cappuccino opt for the “Fat Client” methodology, for anyone who has not heard of this (other than in the literal sense), this means that the client (browser) is made to do more of the grunt work usually accomplished by the server. This has a huge benefit of making the app feel much “snappier”, as common calculations, concatenations etc. are all done on the client-side, reducing the amount/size of calls to the server. Your server-side app acts more like a dumb data store, using REST to communicate data back and forth.

The downside to fat clients (I won’t do the obvious joke), is that there is a chance that your audience will see more than you want them too when visiting “View Source”. You obviously don’t want to give away Granddad’s age-old secret hangover cure in the Javascript source, however as long as you’re sensible and keep the business logic that is of any real value at the server-side, all should be fine.

Fat Framework

Unfortunately, in order to have the additional work handled by the client, you have to feed it more Javascript. The whole of SproutCore comes in at an impressive 500Kb uncompressed! That said, it will compress down to 100Kb when minified and gzipped.

Lets say you went with plain old jQuery as it’s smaller, and you’ll just add plugins for the bit’s you need. Well, by the time you include a chunk of jQueryUI when you want to be able to sort lists and drag stuff around… you’ve soon hit that 100Kb threshold.

So… is the size really an issue by the time it’s all been cached by the browser, images sprited, scripts concatenated into one file etc?

Alternatives

Cappuccino

One of the alternatives already mentioned is Cappuccino. To me the instant turn-off was Objective-J, it’s very clever and all that but do I really want to have to learn another language when I already have Javascript under my belt. Objective-J may have the benefit of easing portability to desktop apps, however I can’t see that this will ever be a flawless process.

UKIJS

Another lightweight alternative is UKIJS which aims to bring the core UI element of the aforementioned frameworks, without the kitchen sink that comes with it.

I’ve had a brief play with UKIJS and generally love the concept, however I can’t help but think it would be better built on top of jQuery instead of borrowing so much of the internals. Also as it is a young project, there are large gaps in the functionality, such as reordering of lists, custom cells in list view etc.

This is definitely one to watch as it seems like a great light-weight alternative to it’s bulkier competition.

Conclusion

I have only scratched the surface in my search for the best framework out of these options. My next job is to play with SproutCore a little more, to see if it caters for what I need.

Has anyone else had experience with these frameworks? What was the conclusion? Should we just abandon Unobtrusive Javascript when building web “Apps” and use it only for web “Sites”?

After taking my first look at SproutCore, I couldn’t help but find the truncation of this documentation page title amusing…

I’ve just finished watching the latest Railscast… thanks Ryan, great as ever! One thing that bothers me is that we are still not able to delete items with the default CRUD setup when javascript is turned off.

Way back in 2006, I wrote an article called Simply RESTful… “The missing action”. I still believe that we should have a “delete” action that responds to GET requests by default in Rails, much like the “update” action has an “edit” form. Now before you say “that’s ridiculous Jamie”, I am not suggesting that we should be able to delete via a get request (that would be stupid!), the “delete” action would simply be a confirmation page with a form that posts to the “destroy” action. That way we can still use javascript to hijack the “delete” link and make it perform a “DELETE” request to the “destroy” action but we also have the benefit of being able to delete things without javascript.

Remember, the “delete” action is to “destroy”, what the “edit” action is to “update”. So in the case of a “products” resource, we would simply render the following form named “delete.html.erb”:

<h1>Delete product</h1>
<p>Are you sure you want to proceed?</p>
 
<% form_tag product_path(@product), :method => :delete do %>
  <div><%= submit_tag 'Confirm delete' %></div>
<% end %>
 
<p><%= link_to '&laquo; Back', products_path %></p>

What do you think?

I’ve had a set of rather bespoke requirements for authentication on a recent project and thought I’d give Devise a go.

Devise uses Warden, which is an authentication solution build on Rack making it extremely flexible and usable across multiple frameworks e.g. Rails/Sinatra. Also, Devise is extremely modular meaning to can easily write custom “strategies” for specific behaviour.

I have used Clearance in the past which is great if you want an engine that will just work. Devise however is by far the most flexible and extensible solution that I have come across with the same ease of use as Clearance. The only thing that you don’t get with devise that you do with Clearance is the signup stage, however as this is normally custom on a per-app basis I can live with this.

One more thing to note is that Devise lets you have multiple auth systems in play e.g. one for users and one for admins.

A quick note on how to delete a tag from a remote git repository:

git push github :refs/tags/my_tag

Just a quick post to say that I will be slowly releasing the ruby gems used at SonicIQ over the next few weeks/months. The first (more to test the workflow of Jewler/Gemcutter/Github than anything), is IQ::HTML.

IQ::HTML is a super simple gem with a few helpers for creating html markup much like you’ll see in ActionPack, however this is it’s only task and is therefore useful when you don’t want the extra weight of ActionPack.

Next up will be IQ::Form which currently exists on Github but is undergoing significant changes so I would suggest waiting for the new release.

I have just had my sexy validations patch excepted into Rails. Much thanks to José Valim for helping me get this applied.

The reason for the name “sexy validations” is that it gives a much more concise way of defining validation and reusing custom validator classes. Much like what sexy migrations did for defining your database schema.

Simple example of using existing Rails validations, the “sexy” way:

class Film < ActiveRecord::Base
  validates :title, :presence => true, :uniqueness => true, :length => { :maximum => 100 }
  validates :budget, :presence => true, :length => { :within => 1..10000000 }
end

The power of the “validates” method comes though, when using in conjunction with custom validators:

class IntenseFilmTitleValidator < ActiveModel::EachValidator
  def validate_each(record, attribute, value)
    record.errors[attribute] << "must start with 'The'" unless value =~ /^The/
  end
end
 
class SpendValidator < ActiveModel::EachValidator
  def validate_each(record, attribute, value)
    spend = case options[:size]
      when :big then 100000000
      when :small then 100000
    end
    record.errors[attribute] << "must not exceed #{spend}" if value > spend
  end
end
 
class Film < ActiveRecord::Base
  validates :title, :presence => true, :intense_film_title => true
  validates :budget, :spend => { :size => :big } # using custom options
end

All validations in Rails, along with other common model functionality have been extracted into ActiveModel, so you can also use validations and Validator classes without ActiveRecord e.g.

class EmailValidator < ActiveModel::EachValidator
  def validate_each(record, attribute, value)
    record.errors[attribute] << (options[:message] || "is not an email") unless
      value =~ /^([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})$/i
  end
end
 
class Person
  include ActiveModel::Validations
  attr_accessor :name, :email
 
  validates :name, :presence => true, :length => { :maximum => 100 }
  validates :email, :presence => true, :email => true
end

Have fun!