To AJAX or Not to AJAX? That is the question!

0

When faced with a new web project these days you typically hear the clients listing AJAX as one of the must haves in their brand new web application. Pretty cool as you might be accustomed yourself to AJAX to the extent that you can hardly imagine returning back to the page reload per click days. But, if you are more sensible (or better yet, your clients are so) you would think twice before entirely abandoning the normal site browsing model for an AJAX based one.

Why? I hear you say. Many reasons, including the fact that we live in the early 21st century, where – get ready for this – not all Internet access devices are equipped with state of the art browsers that can consume your AJAX interfaces or whatever Javascript or CSS magic you throw at them. Many mobile phones (millions to say the least) can hardly parse plain old HTML, some can do CSS but not Javascript

Ok, you tell me. “I will have to do two versions, one that is full of AJAX effects and one old boring HTML only version.” STOP IT, I say, you can't be more wrong. Thank God there could be more elegant solutions to the problem than just writing another application around the same database. I present to you my humble take on the problem. Using the Ruby on Rails Framework (you can apply similar thoughts in other frameworks if you like, and many ideas can be copied easily as they only involve Javascript)

First off, the controllers. The controllers are responsible for receiving requests and sending responses. What we need to do is make them intelligent enough to understand different types of requests and respond accordingly. This is done using Rails magical method “respond_to”

class IssuesController < ApplicationController
def index
...
respond_to do |format|
format.html { # do something }
format.js { # do another thing }
format.json { # and another thing }
format.xml { # ok, enough }
end
end
...
end

In the above example we see that each format will have a different response. This is great for a start, that way we can implement slightly varying responses for the AJAX and the none AJAX calls. To make things easier on us we will implement a very simple case of AJAX. Each rhtml view is rendered in a DIV tag within an rhtml layout. In the none AJAX model, pages are rendered by rendering both the layout and the inner view. In the AJAX model, only the inner view is rendered and is sent back to the browser to replace whatever resides in the content DIV.

So, our controllers will work as follows:

class IssuesController < ApplicationController
def index
...
respond_to do |format|
format.html # will render index.rhtml
format.js { render :layout => false }
# the above line will render index.rhtml but without the layout
end
end
...
end

The above lines made our controller ready to respond to normal or AJAX requests (given that AJAX requests will have the .js format). In the former case it will return back the whole page but in the latter it will omit rendering the layout and only send the content.

Ok, but what we still need two views. I hear you, and fear not, you will have to change nothing. Actually it's only a trivia to adapt your views to this model. Let's see how this can be done.

Here's a normal view code sample, and pardon me, I won't use the link_to helper method for clarity purposes:

...
<div id=”content”>
...
<ul>
<li><a href=”url1”>Link1</a></li>
<li><a href=”url2”>Link2</a></li>
<li><a href=”url3”>Link3</a></li>
</ul>
...
<form target=”url4”>
...
<input type=”submit”>
</form>
...
</div>
...

The above fragment shows a list of links and a form. All should behave in the normal way and reload the page when clicked. Now let's imagine that the user is using a Javascript capable browser. What effect could this coming fragment have on his experience?


<!-- Warning, this fragment requires prototype.js -->
<script>
function ajaxifyLinks(){
// check if there is AJAX support
if(!Ajax.getTransport())return false;
// loop on all links
$$('a').each(function(link){
// attach an event observer to each link's 'onclick' event
Event.observe(link, 'click', function(event){
// call the original url (with .js added) with AJAX
new Ajax.Updater('content',link.href+”.js”);
// stop the browser from following the link
return false;
});
});
// loop on all forms
$$('form').each(function(form){
// attach an event observer to each form's 'onsubmit' event
Event.observe(form, 'submit', function(event){
// send the form contents via AJAX
new Ajax.Updater('content',form.action+”.js”,
{params:Form.serialize(form),
method:'post'});
// stop the browser from submitting the form
return false;
});
});
}
</script>

The above code will transform EVERY link and form in the page to AJAX, that is, in case that the browser supports both Javascript and AJAX. Otherwise links and forms will remain untouched and they will behave as usual.

Of course this is a minimalistic example. We knowingly avoided touching on any special case but, in another installment of this article we will get more intimate with the subject and may be we can handle more aggressive ... techniques!

Using action+client caching to speed up your Rails application

0

Labels: , ,

Too many visitors are visiting your website and loads of dynamic data are being delivered to your clients?. Of those visitors, you have more people reading your site's content than people modifying it? meaning, you get lots more GET requests than POST, PUT or DELETE?

If the above questions are all answered with a YES, then, my friend, you are desperately in need of caching. Caching will help you lessen the load on your servers by doing two main things:
  1. It eliminates lengthy trips to the (slow by nature) database to fetch the dynamic data
  2. It frees precious CPU cycles needed in processing this data and preparing it for presentation.
I have faced the same situation with a project we are planning, we are bound to have much more GETS than any other HTTP command, and since we are building a Restful application we will have a one to one mapping between our web resources (urls) and our application models. The needs of our caching mechanism are the following:
  1. It needs to be fast
  2. It needs to be shared across multiple servers
  3. Authentication is required for some actions
  4. Page presentation changes (slightly) based on logged in user
  5. Most pages are shared and only a few are private for each user
We have two answer the following now, what caching technique and what cache store we will use?

The cache store part is easy, memcached seems like the most sensible choice as it achieves points 1 & 2 and is orthogonal to the other 3 requirements. So it is memcached for now.

Now, which caching technique?. Rails has several caching methods, the most famous of those is Page, Action and Fragment Caching. Greg Pollack has a great writeup on these here and here. Model caching is also an option, but it can get a bit too complicated, so I'm leaving it out for now, it can be implemented later though (layering your caches is usually a good idea)

Page caching is the fastest, but we will use the ability to authenticate (unless we do so via HTTP authentication, which I would love to, but sadly is not the case). This leaves us with action and fragment caching. Since the page contains slightly different presentation based on the logged in user (like a hello message and may be a localized datetime string) fragment caching would sound to be the better choice, no? Well, I would love to be able to use action caching after all, this way I can server whole pages without invoking the renderer at all and really avoid doing lots of string processing by Ruby.


There is a solution, if you'd just wake up and smell the coffee, we are in Web 2.0 and we should think in Web 2.0 age solutions for Web 2.0 problems. What if add little JavaScript to the page that dynamically displays the desired content based on user role. And if the content is really little, why not store it in a session cookie? Max Dunn implements a similar solution for his wiki here and thus the page is served the same with dom manipulation kicking in to do the simple mods for this specific user. Rendering of those is done on the client so no load on the server, and since the mods are really small, the client is not hurt either, and it gets to get the page much faster, it's a win win situation. Life can't be better!

No, It can!. In a content driven website, many people check a hot topic frequently, and many reread the same data they read before. In those cases, the server is sending those a cached page yes, but it is resending the same bits which the browser has in it's cache. This is a waste of bandwidth, and your mongrel will be waiting for the page transfer to finish before it can consume another request.

A better solution is to utilize client caching. Tell the browser to use the version in its cache if it is not invalidated. Just send the new data in a cookie and and let the page dynamically modify itself to adapt to the logged in user. Relying on session cookies for dynamic parts will prevent the browser from displaying stale data between two different session. But the page itself will not be fetched over the wire more than once, even for different users on the same computer.

I am using the Action Cache Plugin by Tom Fakes to add client caching capabilities to my Action Caches. Basically things go in the following manner:
  1. A GET request is encountered and is intercepted
  2. Caching headers are checked, if none exists then proceed
    else send (304 NOT MODIFIED)
  3. Action Cache is checked if it is not there then proceed
    else send the cached page (200 OK)
  4. Action processed and page content is rendered
  5. Page added to cache, with last-modified header information
  6. Response sent back to browser (200 OK + all headers)
So how to determine the impact of applying these to the application
  1. We need to know the percentage of GET requests, which can be cached as opposed to POST, PUT and DELETE ones
  2. Of those GET requests, how many are repeated?
  3. Of those repeated GET requests, how many originate from the same client?
Those numbers can tell us if our caching model works fine or not, this should be the topic of the next installment of this article

Happy caching

Aiming at technology trends

2

How many times you were left high and dry after a very promising technology or product that you so much believed in just vanished in front of your eyes?

inversely, how many times you felt that joy when you made sure that this emerging technology you embraced or evangalized is actually gaining real momentum?

For me, my path in the technology sector has been a mix of both. Does that mean anything? does it say anything that every technology you adopt booms/busts?

In my silly 10 years of following the computer industry in general I had the following adoption failures:

  1. Cyrix, the little company that could! I was amazed by the capacity of their small team of engineers. But they just couldn't stand the tough fight. Bye Bye Cyrix.

  2. BeOS, a piece of engineering beauty. At least in the usability dept. I learnt my C++ by carefully studying the BeOS AP. I did almost all my low level coding attempts on BeOS. I even learnt bash on BeOS. I wasn't grasping why not every body on earth is using it! Silly people I thought (and still think :P). BeOS is no more, RIP BeOS (would be happy to see it ressurected one day though)
Not a long list, what about successes?

  1. Hibernate the ORM man, I knew it was a hit the day I saw their documentation, those guys new their stuff! I joined the ranks in the early version 2.0 days (Gavin's rewrite of the thing). You can still see me grin each time I see a developer using Hibernate at the place where I work.

  2. Javascript for semi-fat clients, it was the year 2000 and the use of Javascript for more than form validation was a taboo for many (browser compatability hell). Not for me, at the place where I work we fully embraced Javascript, and it (almost) never failed us!

  3. Ajax, we've already had such functionality, but since reading adaptive path's article, I really saw what I was missing by avoiding the XMLHTTPRequest object. In a week or so I had an ajaxified wroking protoytpe of our flagship application.

  4. Ruby on Rails, not really an early adopter (managed to use it for production in the pre 1.0 days). I still get this feeling of joy whenever I hear about another success (many of those these days). Rails has come out of age, that's for sure.
Wow, that's 100% more than the failures list, I am glad that this is case though I dont think it proves anything

Now what about the products/technologies I'm looking at now?
  1. Ubuntu? Debian was already great. Ubuntu is the icing on the top of the cake. This one might boom.

  2. Offline web apps (sometimes connected apps, discussed here). These are just around the corner. If they manage to break the chasm before wireless technology covers the whole planet they will enjoy great success (for a while at least).

  3. The new wave of falling back to the forgotten REST API. I beleive we have a winner here. Specially when you see something like this coming out of it
Things that I hate/think will fail/would like to see fail

  1. JSF, I believe one day people will realize that building interfaces is not like building a brick wall. That's the day JSF and the likes will be burnt for witchcraft!

  2. PHP, combine an ugly inconsistent sytanx with a terrible extension API and you've got yourself a PHP clone. Even though I managed to write decent apps in PHP but wouldn't like to live this experience again.
That's enough for a wish-to-fail list, 2 items and I already feel the high blood pressure, I just don't want to get started on the giants now.

Every body will have his own pattern of failures/successes in following trends. Would be interesting to see what others think.

Rob Williams on Ruby, Jibberish and English

2

I was amused to read Rob William's take on a Ruby article in SD Times. Aside from his sarcasm, he scores home with most of the arguments though I beg to differ with some of them. I will highlight some of my opinions and respond for Ruby :)
  1. Our tools do that.!! The article was pointing to how Ruby follows the Unified Access Principle where you only have one interface to the class data members, whether it is a simple storage operation or a complex one. But, as Rob points out, having such support in the language is useless because current tools do that. I bet Bertrand Meyer wouldn't roll on his grave because Ruby is trying to offer UAP even when there are such tools around.
    # initial class
    class Plan
    attr_accessor: owner
    end

    plan = Plan.new
    plan.owner = rob
    plan.owner # => rob

    # we now need to upgrate to a full fledged setter
    # rather than the one dynamically generated for us above
    class Plan
    attr_accessor: owner, assigned
    def owner=(owner)
    @owner = owner
    @assigned = true
    end
    end

    plan = Plan.new
    plan.owner = rob
    plan.owner # => rob
    plan.assinged # => true

  2. Long code is like short code is like medium code! Rob is picking at the author for mentioning that Ruby produces less lines of code. He's arguing that the tool is producing those verbose Java lines for us too!. As if we should accept garbage only and only if it is spit at us by our favourite tool! Why don't we all ditch the use of annotations for Hibernate mapping when our eclipse XML editor does autocompletion for the .hbm files? it is not about too many lines of code, it is about clutter and organization. I long for the day when i used VisualAge for Java, It was really anti clutter! (written in SmallTalk, no less!)
    # neat example on short code
    session.time_out = 48.hours.from_now
  3. Rob rightfully accused the author to have poorly written the testing section and dynamism. The author was seemingly speaking about mock objects and how using them in a dynamically typed system is easier than a statically typed one. In a dynamic setting, identifying a mock object and using it is seamless. Also writing the mock object itself is seamless, no interface or contract of some sort, you only code the methods that you intend to handle and the others are handled by a common method. It's rather interesting to see that almost all the Java guys would praise AOP and tell stories about the wonders that they achieved using AOP (many are actually finding their way around the static nature of Java through AOP)
    class Person
    def can_run?
    # some tedious operation
    end
    def can_jump?
    # some other operation
    end
    end

    # person mockup
    # returns true whenever the method called has the character ?
    class PersonMockup
    def method_missing(method_id)
    method_id.to_s["?"]
    end
    end

    # or for some dynamic magic
    class Roman
    def roman_to_int(str)
    # do conversion here
    end
    def method_missing(method_id)
    roman_to_int(method_id.to_s)
    end
    end

    roman = Roman.new
    roman.V # => 5
    roman.IV # => 4
    roman.VII # => 7
  4. "ActiveRecord is simplistic". Here Rob doesn't justify why he thinks AR is rather simplistic? may be he is commenting on the simple example given by the article author? AR is rather a simple interface for a stunningly powerfull engine that provides you with a wide variety of DB constructs, the has_many and sisters, are actually defined in the AR module and when invoked they add methods and functionality to the invoking class at the class definition time. And due to Ruby's syntax flexibility they fit naturally in the class definition you don't even notice that they are function calls but rather some seamless annotation of some sort (which actually affects the class being declared and adds methods and attributes dynamically to it). Ruby provides you with the ability to add even more of those to AR. By excercising this feature you can build very complex relations between your domain models and still keep your code clean and clutter free.

    class Person < ActiveRecord::Base
    has_many :plans
    has_many :tasks, :through => :plans
    end

    class Plan < ActiveRecord::Base
    has_many :tasks
    belongs_to :owner, :class => "Person"
    end

    class Task < ActiveRecord::Base
    belongs_to :plan
    acts_as_tree #defines parent/child relation ship among tasks
    acts_as_taggable #for folksonomy aware objects (AR plugin)
    end

    #get all completed tasks for rob (involves one hit to the database)
    completed_tasks = rob.tasks.select{|task| task.completed?}

    #get all completed tasks that are parents for other tasks
    completed_prent_tasks = completed_tasks.select{|taks|!task.children.empty?}

  5. On DSLs. There are many ways one can solve a problem, but if you can shape your language around the domain you're attempting at that makes for much clearer code (wich is evident by looking at the above example) DSLs are abundant in Ruby code, mainly because the language has enough metaprogramming constructs and syntax flexibility that promotes such an approach to problems. Here are a few examples on how you can shape your code around your specific problem domain in a way that a domain expert will naturally understand the code.
    # using a dsl suited for representing a workflow
    workflow "default" do
    step "scan"
    step "ocr" do
    when_error "manual"
    end
    step "cleanup"
    end

    workflow "manual" do
    step "correction"
    step "distribute"
    end

    #or a dsl for meal recipes
    recipe "PBJ Sandwich"
    ingredients "two slices of bread",
    "one heaping tablespoon of peanut butter",
    "one teaspoon of jam"
    instructions "spread peanut butter...",
    "spread jam...",
    "place other slice..."
    servings 1
    prep_time "2 minutes"

    #another dsl from rspec
    target.should.equal 7
    target.should.not.equal 5
    target.should.be Fixnum
    target.should.contain 'a'
    target.should.be.empty
    target.should_respond_to :quak #for the love of the duck!

    #or from the poignant guide :D
    class Dragon < Creature
    life 1340 # tough scales
    strength 451 # bristling veins
    charisma 1020 # toothy smile
    weapon 939 # fire breath
    end

  6. camelCaseVariablesLookPrettyNeatAndAreSoSweet , on the other hand underbar_variables_look_terribly_ugly_and_dull . That's what Rob thinks I suppose. I wont comment on Rob's taste, to each his own. I used to think like him, not any more.
    testHasThreeClientsAndOneSupplierAndTwoStores()  //pretty java

    test_has_three_clients_and_one_supplier_and_two_stores #ugly ruby :)

I have to stop before this turns into a Ruby vs. Java thing (a typical my daddy is bigger than your daddy duel) or did it happen already? Anyways, Rob was complaining from the poor quality of the article, which is largely true (I bet he'd complain from the poor quality of my writeup too, but would that stop me?). My issue is that harm was done to Ruby the language in the exchange, that's why I tried to shed some more light on the issues mentioned. I dont hate Java, I just think I had too much coffee ;)

To each his tools, to each his rules

oldmoe

"My opinion is right, though it could possibly be wrong. Your opinion is wrong, though it could possibly be right", Imam Shafey

Guide: Environments in Rails 1.1

0

This article covers what environments in Ruby on Rails are, how they are configured, and how you can create custom environments outside of the stock development, test and production.

read more | digg story

acts_as_taggable_tag (take two)

0

It's been a while since I wrote any update on that topic, but I'm glad that I will be reporting good progress this time.  The acts_as_taggable_tag (AATT from now on) plugin is shaping up nicely (along with my Ruby and Rails knowledge).

Currently the AATT is a real plugin that lives in /vendor/plugins in your rails app. The plugin enables you to do that to any of your models

class Person < ActiveRecord::Base
    acts_as_taggable_tag
end

This simple invocation adds the following to your model class

    #These methods are called to define the relations
    has_many :tag_joins, :class_name => "Tagging", :as => :tagged_one
    has_many :tagged_one_joins, :class_name => "Tagging", :as => :tag
       
    #These instance methods are defined for your model
        tags                   #returns a list of objects that tag yours
        tagged_ones            #
returns a list of objects that are tagged by you
        tag(tagged_one)        #tag this object by yourself
        remove_tag(tag)        #remove this tag from you
        clear_all_tags         #delete the relations between you and your tags
        clear_all_tagged_ones  #delete the relations between you and objects tagged by you


If you look at the implementation of the above methods you'll notice how inefficient they are (a select call for each tag on a certain object for example). Performance is not my primary concern at this point in time, I am just trying to get the concept right.

A class is created for the  dual polymorphic join model (name Tagging). Currently the name and the table mappings are not configurable (you have to use what I give you, period). The table structure is available in a migration format and can be invoked by:

    rake import_aatt_schema

and it can be dropped from the database using:

    rake drop_aatt_schema

I will be preparing a .zip file containing the plugin. To install it you only need to unzip it in the vendor/plugins directory. A great guide to using plugins can be found here

acts_as_taggable_tag

1

acts_as_taggable provides a very easy means for tagging various objects in your Rails application. By using this plugin you can now add a tag to every object and even look at those objects from the tag's point of view; thanks to :polymorphic => true.

I was entertaining the idea of using tagging in a system that I am intending to build. There would be a very generic framework that consists of a certain basic element that can be tagged by different types of tags. I then realized that this was actually the opposite of what acts_as_taggable does!. acts_as_taggable defines a single tag type that can be applied to any object. This lead me to thinking, why not join both ideas? And hence the acts_as_taggable_tag.

acts_as_taggable_tag is not yet a module, but I couldn't resist the name ;). What it does is that it simply enables any object to act as a tag for another object even if it was of the same class or even if it was tagging itself! Thus implementing dynamic many to many associations across all your persistent domain objects through tags

The caveat though is that has_many :through does not play nicely with polymorphic associations as explained here . I ended up using only the join table (taggings in my case) and adding methods for retrieving both the objects that act as tags for the current object and the objects that are tagged by the current object

This implementation is a bit lacking when it comes to performance. What would make it sweet though is to enable :polymorphic associations with a has_many :through, looks like the next thing to dig into :)

Now for the code:


Person Class
class Person < ActiveRecord::Base
has_many :tag_joins,
:class_name =>"Tagging",
:as => :tagged_one
has_many :tagged_one_joins,
:class_name => "Tagging",
:as => :tag

def tags
self.tag_joins.collect { |tj| tj.tag }
end

def tagged_ones
self.tagged_one_joins.collect { |tj| tj.tagged_one }
end
end

Message Class
class Message < ActiveRecord::Base
has_many :tag_joins,
:class_name =>"Tagging",
:as => :tagged_one
has_many :tagged_one_joins,
:class_name => "Tagging",
:as => :tag

def tags
self.tag_joins.collect { |tj| tj.tag }
end

def tagged_ones
self.tagged_one_joins.collect { |tj| tj.tagged_one }
end
end

Tagging Class
class Tagging < ActiveRecord::Base
belobgs_to :tag, :polymorphic => true
belongs_to :tagged_one, :polymorphic => true
end

The code in the Person and Message classes is identical, now each of them has a list of tags and a list of tagged_ones each containing whatever objects of whatever classes that happen to tag or be tagged by the current instance of Person or Message

The Tagging class represents the double polymorphic association between the tagging object and the tagged one regardless of the Class. This approach can be used to implement all sorts of hierarchies among your persistent objects through tagging. I am using it to build a multi process project management tool, which through tags can create different views of the same data like an Iteration/Story one for something like XPlanner or a TodoList one for the BaseCamp style.

What's next is to look at how to modify AR so it will accept polymorphic associations with a has_many :through. But that can wait, I'm already glad that I can tag with such a flexible structure.

Happy tagging :)

White collar cultures (A.K.A multinationals)

2

This is not a whining post (at least I dont intend it to be so). I'm just trying to think out of the box for a change.

For the past few months I was surrounded by more white collars than ever in my life. Mr. IT Manager this and Mr. IT Manager that, even Mr. Director of Technical and Non Techncial Economic Hyper Relations at PSGCD (their names happen to puzzle you somtimes, dont they?).

And guess what? meetings to these people are like water to a fish, they can hardly survive out of the meeting room. We need to change a label? let's throw an ultra high level management meeting for three companies and let everyone and his brother join in. Now after 3 hours of brain trashing everyone agrees that the label really needs changing, and a follow up meeting is set to decide on the actual label to be used (ofcourse that's an exaggeration so take it with a grain of salt,...or two!)

I just heard a comment saying the I should be doing more meetings and less programming! I beg your pardon, programming is MY WATER! I dont imagine myself laying back and moving things by pointing a stick at them. I'm not an ivory tower type of a manager either. And I dont like the constraints that conventional management and white collar cultures are putting around me.

The joke is, after all that, those white collars are COSTING US MONEY! you'd imagine that working with multinationals is like having a cash cow, rather it's like having a fake cow for display (and no milk at all). You only have to deal with complicated requirements (that dont even make sense sometimes), very eager expectations, very slow payment and very limited technical assistance (up to the level of requiring us to travel between cities to install files).

I bet you're asking now: "why are you putting up with all of this?", I just asked myself the same question, and hence that (seemingly whining!) post :)

I'm still pondering it all in my mind, where should we (or I?) be directed, how can we be happy? and I mean HAPPY!

I'd quote DHH here, "so be happy"

Changing Jobs

1

I'm back at this again! Changing jobs for the.... well... for the second time in my career! I'm even moving back to my old place!. I hope this move will prove fruitfull. By all means, I will try to make it so inshaAllah.

Prayers in Ramadan!

0

Here's a link for some photos of the prayers in the last nights of Ramadan. I can be found somewhere in the crowds :). I was very impressed by the numbers!. I only hope this trend continues.

Ramadan..

0

It is time for Ramadan again (the month of fasting for us Muslims). I hardly can find time to blog because of the many things to do. I hope I will be back in shape soon. Happy Ramadan to Muslims every where. Happy Ramadan to humanity.

JSTemplates

5

Our code base became largely infested with lots of JSTemplates (Javascript templates from trimpath.com) . We are using them for almost all view rendering now. JSTemplates are great but there are certain areas where they keep you wanting more. I'll try to put those issues into prespective here:
  • No remote includes!
    It would be great if one could just include a url in a template. But how could this be done? and the latency? these are questions that arise when speaking about such a feature
  • InnerHTML based!
    since they always return a string representing the rendred template the only reasonable way to use it is to set it as the innerhtml of some html node in your document. While this is a normal practice it has some drawbacks!
    • once you set the inner html of an object the control is immediately returned before the content is actually parsed and added to the dom tree
    • so if you want to access an element just after the template was rendered you might find it not yet available as a dom node!
    • While every benchmark on that issue says that setting innerhtml is the fastest thing on earth I believe that dom manipulation is much faster (the benchmarks count only the time needed to create the string and assign it to the node, not the parsing and rendering time!)
So here we have them! only two issues :)

The first is really not that important. It is the second one that bugs me! I think one solution would be to parse the rendered template yourself and create the nodes as you go and after you finish you append them to the container. But this would be much slower than the browser's implementation! An alternative would be an event that fires when the browser finishes the rendering! would that be possible? I think it could be done one way or another (like every render function returns a unique id of an object it appends to the end of the template. This is looked for on a timeout or interval method which would fire some callback if it is found).

Just some thoughts. Aside from that JSTemplates are ultra cool!

(AOJP) Aspect Oriented Javascript Programming

0

Update: I did a newer implementation here

In an attempt to trace the program flow of our Javascript client application we needed a stack trace of function calls. We needed to eliminate unneeded redraw and keep the code flow intact.
Over at deep some amazing AOP stuff in Javascript can be found. So what we did to print the stack trace? only an advice is added before all the interrested functions (Javascript has enough reflective abilities for us to be able to inject these advices along our object graph dynamically). And now we have a nice and accurate call stack! Ofcourse many cases of redraw are gone now. And we introduced another feature into our Javascript beast, AOP capabilities!

Move the view to the browser

0

Any self respecting MVC framework would have some sort of view manipulation. Almost all those sever centric frameworks have some sort of view manipulation. You create your views in your templating engine of choice (Velocity, Smarty, ERB, ASP, JSP or whatever). The views are processed by the server and the rendered result is sent to the browser. Some templating and view technologies go an extra step further an enable you to use cached copies of the compiled view templates.

Of particular interest where the SpringMVC and the RubyOnRails frameworks. Both provide means for view handling. And both provide hooks for custom view handlers. Which would lead to the interesting question.

What's wrong with the current view handlers?

All these handlers operate in the classical web application linked pages model (Web 1.0). With the eager move to Single Page Applications (Web 2.0) we need to add these abilities to current frameworks (or create new frameworks?)

How can we acheive this?

Instead of sending complete pages. The server should send to the client data only. And this data should only be view data with no control data. The view control data should reside completely on the client. So instead of responding to a list_items request with a rendered html page with the items required we will only send the data required. To be parsed and rendered by the client browser.

And data format?

Although it seems natural that we use XML for data sending. In a web browser environmnet it is more fit to use a more Javascript friendly approach. JSON (which is very XML like but in native Javascript) can be used as a data interchange medium. JSON will easily be parsed into live Javascript objects. Passed easily to templates (Javascript Templates from trimpath). And used to store model cache if needed (keeping the cache in the native Javascript format rather than XML is crucial for performance).

Template Engine?

As mentioned above. The Javascript Template from www.trimpath.com act as a very good alternative to its server side cousins. It has Smarty, Velocity like syntax. And it is very extinsible. The only draw back is that it is lacking an include mechanism (though this is partially solved by using its Macros)

And the result?

Adding web 2.0 application capabilities to the current tried and true web application frameworks. Making it easy to move even current apps to the user friendly era of web 2.0. I will be working soon in the Spring to JStemplates interfaces and I might delve into a RoR implementation as well (this would be very easy I believe, might envolve overriding a method or two in the action controller). The only thing that is missing is standardizing the client side controller code.

Amr Khaled

0

I just saw Amr Khaled on TV a moment ago. It's been a while since the last episode of his program (life makers) was aired. I really missed the man! He has a way in speaking that manages to capture me every time. Specially at this time before Ramadan. The program was being aired from Egypt which means that Amr actually manages to visit his own country from time to time. My participation in his life makers program was far beyond what I would like to do. I will try to
be more active in the coming months. And I will try to make this Ramadan the best so far. Amr is the kind of man that is able to rally people for a good cause. He is our Gandhi! And more!. I just wish we all give him all the support we can. May Allah reward us all. Amen

Statefull, stateless, statefull....

0

Over at theserverside.com Alexander Jerusalem wrote: Does JSF + AJAX really make sense? He raised some serious questions about how should the client and server interact and how could we maintain the server state when the client updates the form elements dynamically.

His worries are very well founded and stem from the fact that current web application frameworks are mostly server centric. The server is playing a monoply on the data model, action control and even view state.

Here's a look from the other side of the fence. I was not doing much Java development as of late and instead of using bell-and-whistle based frameworks I was participating in a big project that had the following properties:
  • Huge client base that consumed the processing power and the bandwitdh of the server(s)
  • Distributed implementation which should be done as simple as possible due to time constraints
  • Distributed data set (per user data are private and thus caching has no real system wide effect)
  • To stress the first point. Processing and bandwidth were at premium! we had to save on both.
Now the server centric frameworks that are all around us are far from suitable for such a beast. In fact it does not have to be a beast at all! We followed the KISS model and made ourselves a winner!

Recipe for success:
  • Build a stateless server application (only loggedIn? should be tracked)
  • The server only responds to fine grained actions (for some actions the server responded with JSON data, for most of the action the server simply said: "ok")
  • Put this app on as many servers as you wish as long as they share the data and can share the loggedIn? peice of info.
  • Build a statefull SPA client:
    • Full model and model cache (use the cache to avoid visiting the server often)
    • Full fledged controller (the client decides what happens next)
    • Complete View rendering and management (Javascript templates any one?)
  • Connect everything using Ajax and JSON (how thinner can we get?)
  • Forget about HTMLUnit (use your own Javascript infrastructure to test and direct your DOM)
What was good about such an application?
  • Fast prototyping
    We managed to get a prototype (no server side thing) up and running in no time. Even during development the evolving prototype would be one step ahead by relying on static data rather than server responses
  • Prototype reuse
    The prototype actually became the application! It was continously under refactoring but the team managed to always keep it under control
  • Real Distributed Application
    The clients now do the controlling part and the parsing and rendering of view templates. They keep the view state and the model state (through the cache) only updates are propagated to the server. Much less processing on the server(s) now
  • Bandwidth Savings
    Down to 25% of the original bandwidth consumption (more savings expected) and due to decreased server load we are now able to use mod_deflate for even better savings
So did we find ourselves a killer framework for next generation web apps? I doubt! but I believe that we have now the optimum solution for our type of problem. Some other problems might need different solutions and might not benefit from such an approach. But to see Alexander's words in another view: Yes sometimes Ajax and JSF dont co-exist. Sometimes you'll need to drop JSF for Ajax to work the way you want!

What's wrong with AJAX guides?

1

Most Ajax guides available online would tell you how Ajax is our way to the asynchronus client programming. Follow that with an example of how to build Ajax requests with details upto callback management. The poor reader will grab the code and paste it in his/her application and will find it working. After his/her application grows things will start to miss behave. What went wrong? The poor fellow who had little to no knowledge of Javascript (and may be shunned it off earlier as a languange for those who can't do real programming) didnt give the script a good look trying to figure out what's going on first.

Here's an example from developer.apple.com :

var req;

function loadXMLDoc(url) {
req = false;
// branch for native XMLHttpRequest object
if(window.XMLHttpRequest) {
try {
req = new XMLHttpRequest();
} catch(e) {
req = false;
}
// branch for IE/Windows ActiveX version
} else if(window.ActiveXObject) {
try {
req = new ActiveXObject("Msxml2.XMLHTTP");
} catch(e) {
try {
req = new ActiveXObject("Microsoft.XMLHTTP");
} catch(e) {
req = false;
}
}
}
if(req) {
req.onreadystatechange = processReqChange;
req.open("GET", url, true);
req.send("");
}
}

function processReqChange() {
// only if req shows "loaded"
if (req.readyState == 4) {
// only if "OK"
if (req.status == 200) {
// ...processing statements go here...
} else {
alert("There was a problem retrieving the XML data:\n" +
req.statusText);
}
}
}
What's the problem with the above code? specially in an asynchronus environment?

The variable req (which is used as the XMLHTTPRequest object) is defined globally!! So when our friend tries to instantiate a new request before the current one finishes it will overwrite it and you will lose any reference to the old request.

But why did we have a global variable in the first place? If it's so bad, why didnt we make it local tothe loadXMLDoc funciton?

Simple, because the call back function needs to access this variable. And if it cannot be found in its scope it will look at it in the global scope.

Closures any one?

this can easily be solved by defining the call back function as an inner function to the loadXMLDoc() function and declaring the variable req as local to this function
function loadXMLDoc(url) {
var req = false;
// branch for native XMLHttpRequest object
if(window.XMLHttpRequest) {
try {
req = new XMLHttpRequest();
} catch(e) {
req = false;
}
// branch for IE/Windows ActiveX version
} else if(window.ActiveXObject) {
try {
req = new ActiveXObject("Msxml2.XMLHTTP");
} catch(e) {
try {
req = new ActiveXObject("Microsoft.XMLHTTP");
} catch(e) {
req = false;
}
}
}
if(req) {
req.onreadystatechange = processReqChange;
req.open("GET", url, true);
req.send("");
}


var processReqChange = function() {
// only if req shows "loaded"
if (req.readyState == 4) {
// only if "OK"
if (req.status == 200) {
// ...processing statements go here...
} else {
alert("There was a problem...");
}
}
}

}


All we needed to do is declare req as a local variable by adding the var keyword and removing the global declaration.

This way each request will spawn a new req object which will be accessed by the callback function and will be garbage collected after the callback function returns (some browsers - namely older versions of internet explorer - might leak memory here as they deal very badly with closures)

Mubarak won!

0

Great news for all the national party members. Mubarak won the elections with a staggering 88.5%!.
The Egyptians voiced their opinion! and what I conclude for it is :

  1. They dont care for the 19000 wrongfully imprisoned fellow Egyptians
  2. They dont care for being poisoned with illegal pesticides
  3. They dont care if their childern recieve no education at all

which calls for an interesting question, what do the Egyptians care for?

Going Home

0

Another day (and night?) at work. It is 2 A.M. now and still too much left to do. If not for Sheikh Abdel Basset's sweet recitation of the Holy Qur'an I doubt we could handle the stress!. Any way, I must head home now. Tomorrow is (yet) another day insha'Allah.

And more deadlines!

2

Seems the Ajax fever is spreading around. Today I had a meeting with a high profile client that was negotiating building an Ajax prototype to be demonstrated in Gitex!. They were enthusiastic and were talking about the possibilities and I was thinking to myself: "O Allah! no more deadlines!!". Best thing is that they were talking about a 3 weeks deadline which made my refusal much easier!