niczsoft

This story will be about jquery pure templates.

During developing new project I found great library Pure by beebole and I was going to write about it in first place. but with time when using it I found more and more issues with it. My first idea was to fix it, and I started doing that, but in the middle of debugging I found out it’s not that easy, 20KB of sources is hard to change.

So I have decided to write my own code, using very similar idea but different approach. My library is still pure, does not require putting fancy markers into html in manner to fill it with data, it is enough to write code which can be matched by jquery. My first try was with putting selectors directly into data description like:

data = {'a#my':"my url",'a#my@href':"#/url"}

After I got proof of concept in only 3 hours of coding I thought it would be good to allow mapping any keys to a map of selectors, so it is no more required to return selectors as keys of JSON:

data2 = {'name':"my url",'link':"#/url"}

using simple map file:

map2 = {'name':'a#my','link':'a#my@href'}

So how to call it ? Simple :) just include lib in the header:

<script src="jquery-pure-template.js" type="text/javascript" 
        charset="utf-8"></script>

And call render on jquery matching elements:

$('.user').render(data);

or using map file:

$('.user').render(data2,map2);

Thats all needs this html:

<div class="user"><a href="#"></a></div>

and finally you will get as output this html:

<div class="user"><a href="#/url">my url</a></div>

This was simple example, but it will also work with arrays, and nested arrays too, just give it a chance, and keep in mind don’t force html to change the flow, try to make data keep the flow, not view.

Ofcourse there might be certain problems with performance with the chosen approach, first of all performance. Arrays over 500 elements tend to perform quite bad, but using nesting arrays can hold up to 5000 elements without big problem on decent computer. Additionally putting id’s into collection should additionally give some 20% speed up in finding elements by jquery.

I know there are faster solutions, that can probably render lots of data, but mine is simple, only 100 lines now (70 in first version), this makes it extremely easy to maintain and change, hawing less code is better then more :)

This post is also available in Polish version.
Software described here is a plugin for jquery.

Working on my new app I thought it is necessary to get some data from configuration file, there was already plugin that had the necessary functionality – acts_as_configurable.

Unfortunately this plugin was not exactly what I was looking for It had possibility to write configuration in the class itself – I needed configuration in file.

So I did fork of the project, and now you have possibility to use rewritten version of the plugin which uses yaml file for storing configuration.

Here is example configuration file:

default:
  :first: 1st
Settings2:
  :first: 2nd
settings:
  :first: 3rd

With this configuration all the following definitions are valid:

class Settings1
  acts_as_configurable
end
class Settings2
  acts_as_configurable
end
class Settings30
  acts_as_configurable :for => 'settings'
end
class Settings31
  acts_as_configurable :for => :settings
end
class Settings4
  acts_as_configurable :for => Settings2
end
class Settings50
  acts_as_configurable 'conf'
end
class Settings51
  acts_as_configurable :conf
end
class Settings52
  acts_as_configurable :name=>'conf', :default=>'settings'
end
class Settings53
  acts_as_configurable :name=>:conf, :default=>'settings'
end
class Settings60
  acts_as_configurable :name=>'conf', :for => Settings1, :default=>'settings'
end
class Settings61
  acts_as_configurable :name=>'conf', :for => Settings1, :default=>:settings
end
class Settings7
  acts_as_configurable :name=>'conf', :for => Settings2, :default=>'settings'
end
class Settings8
  acts_as_configurable :name=>'conf1', :for => Settings1
  acts_as_configurable :name=>'conf2', :for => Settings2
end

and using following rspec code it will pass tests:

describe "ActsAsConfigurable" do
  it "should respond to 'configuration'" do
    Settings1.configuration.should_not be_nil
  end
  it "should contain default values" do
    Settings1 .configuration[:first].should eql '1st'
  end
  it "should contain values" do
    Settings2.configuration[:first].should eql "2nd"
  end
  it "should contain values for string" do
    Settings30.configuration[:first].should eql "3rd"
  end
  it "should contain values for symbol" do
    Settings31.configuration[:first].should eql "3rd"
  end
  it "should contain values for class" do
    Settings4.configuration[:first].should eql "2nd"
  end
  it "should contain values for object" do
    Settings2.new.configuration[:first].should eql "2nd"
  end
  it "should respond to 'conf' - passed as string" do
    Settings50 .conf[:first].should eql '1st'
  end
  it "should respond to 'conf' - passed as symbol" do
    Settings51 .conf[:first].should eql '1st'
  end
  it "should respond to 'conf' - passed as :name=>" do
    Settings52 .conf[:first].should eql '3rd'
  end
  it "should respond to 'conf' - passed as :name=>symbol" do
    Settings53 .conf[:first].should eql '3rd'
  end
  it "should work with other default - passed as string" do
    Settings60 .conf[:first].should eql '3rd'
  end
  it "should work with other default - passed as symbol" do
    Settings61 .conf[:first].should eql '3rd'
  end
  it "should work with other default but also exisitng for" do
    Settings7 .conf[:first].should eql '2nd'
  end
  it "should work with multiple definitions" do
    Settings8 .conf1[:first].should eql '1st'
    Settings8 .conf2[:first].should eql '2nd'
  end
end

Sources for the plugin are here http://github.com/mpapis/acts_as_configurable

After installation of dozens of plugins to trac I started wondering why people can not simplify their life ?

By ex. MasterTicketsPlugin can draw pretty graphs with great links to other tickets, but … you have to leave the ticket view to see the graph, So my thought was to have the graph on ticket view, as I already had TicketSidebarProviderPlugin I had *only* to embed output of one plugin into new sidebar.

As things look quite straight there were few gotchas which make the task spread to few hours, but finally I succeded and the result is already published at Trac-Hacks.org – DepgraphSidebarPlugin