CGI language choice - mysql

Ok, I've asked a few related questions here and only ended up with more questions and I realized now it's because I don't have enough background info. So I'll make it more generic:
I need to make a simple web application. Static HTML/JQuery pages will send AJAX POST requests to some server side code, which will:
Read the POST variables passed in
Run some very simple logic
Hit a MySQL database for simple CRUD ops
Return a plain string of data to be consumed by the javascript on the page
I was assuming Ruby was a good choice for this as everyone is raving about how well it's designed, and I've been playing with it - not RoR, just Ruby for simple scripting tasks - and I kind of like it.
My question is, I'm hopelessly confused by the trillion helper libraries and frameworks out there. I don't know what these are and therefore if I need any/all of them: Rack, Sinatra, Camping, mod_ruby, FastCGI, etc.
Would it be easier to just learn PHP and us that? Or can I get away with just dropping my .rb files into the cgi-bin folder(I'm using Apache for hosting) and use the ruby cgi library to get my variables?
EDIT: As far as Rails, I'm just assuming that it's overkill for what I want but I might be wrong. I looked at it, and it seemed cool for generating data based web sites quickly, but that's not what I'm trying to do. I don't want any forms pages for the user. I don't want them entering data or viewing records. I don't even want to return any HTML. I just want a ruby script to sit on the server, get passed a few variables in a post request, and return a JSON string in response. I will need some basic cookie/session/state managment
This is a really easy thing to do in C# and ASP.NET with webservices, but it seems very confusing with the open source technologies.

You don't want to use any feature from a fully blown framework so don't use one. Less code = less bugs = less security nightmares.
CGI
CGI has some performance drawbacks in comparison to other methods, but is still (in my opinion) the simplest and easiest to use one. This is how you use the builtin cgi library:
require "cgi"
cgi= CGI.new
answer= evaluate(cgi.params)
cgi.out do
answer
end
rack
Another low tech easy to use variant would be rack. Rack is an abstraction layer which works for many webserver interfaces (cgi, fastcgi, webrick, …). It's simplicity can be compared to the one of only using cgi. Put the following into a file wich ends with .ru into your cgi directory.
#!/usr/bin/rackup
require "rack/request"
run (lambda do |env|
request= Rack::Request(env)
anwser= evaluate(request.params)
return [200, {}, answer]
end)
This does not seem very different from cgi, but it gives you much more possibilities. If youst execute this file on your local machine rackup will start the webrick webserver. This webserver will deliver the webpages you described in your .ru file.
Other interfaces
fast-cgi
fast-cgi works almost like CGI. The difference is, in CGI your script get's started for every request it has to work on. With fast-cgi, your script only starts once for all requests. There is a library available to write fast-cgi script in ruby.
mod_ruby
mod_ruby is a builtin ruby interpreter for apache. It works analog to mod_php in apache.
mongrel
mongrel is a standalone webserver for ruby applications. This is a simple hello world example with it.
require 'mongrel'
class SimpleHandler < Mongrel::HttpHandler
def process(request, response)
response.start(200) do |head,out|
head["Content-Type"] = "text/plain"
out.write("hello world!\n")
end
end
end
h = Mongrel::HttpServer.new("0.0.0.0", "3000")
h.register("/hello", SimpleHandler.new)
h.run.join
Mongrel is often used for rails and other ruby frameworks. Most people use an apache or something else on port 80. This webserver than distributes the requests to several mongrel servers running on other ports. I think this is totaly overkill for your needs.
phusion passenger
passenger is also called mod_rails or mod_rack. It is a module for apache and nginx to host rails and rack applications. According to their websites rails with passenger uses 1/3 less ram than rails alone. If you write your software for rack, you could make it a little faster by using passenger, instead of cgi or fast-cgi.

Use jQuery and PHP.
Both technologies are well documented, and you should be able to get an application up and running in a matter of hours. You sound like you know a thing or two - talking about CRUD operations and so on - so I won't bore you with examples. And as far as JSON goes, there are probably a million PHP libraries out there, for outputting JSON objects.

Sinatra is very simple to learn and use. It's also easy to deploy with the use of Phusion Passenger (which is like mod_php for ruby frameworks like Rails and Sinatra). Instructions here: http://blog.squarefour.net/2009/03/06/deploying-sinatra-on-passenger/
If you find that you need more than what Sinatra will give you, I recommend Rails. Setting up that with Passenger is even easier since hardly any configuration is required. (see modrails.com).

PHP is very easy to use because it's designed specifically for this sort of thing. Want to read POST variables? They're in $_POST. Want to query MySQL? mysql_query("SELECT `something` FROM `table`");. And if you ever need help, Google searches for "php what_you_need_to_do" almost always return results on php.net, which is very helpful.
And for what you're doing, you don't need any additional frameworks.

I am curious about what I perceive to be your resistance to trying Rails. You say that you want "to spend more time on the scripting itself and less on configuration", and yet you seem to dismiss Rails out of hand. Rails is all about convention over configuration. If you take the time to learn how Rails does things, you can get an incredible amount of functionality "for free" just by following the conventions of the framework.
If you want to make a simple web app, Rails is really a very painless and good way to start. You can use a sqlite database and not even mess with MySQL (won't scale, but for learning or simple apps it's fine). It's true that there are simpler frameworks, but since you seem new to web programming, I'd recommend that you start with what will get you the most support in terms of documentation and knowledgeable folks. Follow the old adage: Get it working first, then optimize later.
The only sticking point I can see is the Apache integration... The consensus on Rails deployment these days seems to be focused on using lightweight httpds in place of Apache. There is a mod_fcgid which seems to be the best way to do it with Apache (mod_ruby is deprecated, buggy and slow, last I read) if you can do custom mods. Or there's Phusion Passenger, which seems to be the latest and greatest way to do it. Running Rails in a standard CGI environment will yield awful performance (but that goes for any CGI framework, really) due to the overhead of executing the interpreter + framework for every request. You'll get much better performance if you go with something that keeps the interpreter + framework in memory.

I personally like Django. I had a problem with Ruby on Rails where I just got overwhelmed by everything when I just wanted to do something simple, which it sounds like you want to do (since you said ROR feels like overkill). The cool thing I found with Django is that if you WANT everything, then you can get everything by plugging it in...but if you want less then you just don't plug in that technology and it's that much more lightweight.
Take for example "views". Django, like ROR, uses MVC. But if you just want to return a string of data and don't need the view, then you don't need to plug in the view. But if later on you decide that it will be more organized in a view then you can easily plug it in at that time.
Here's their website: http://www.djangoproject.com/

Related

Login/Registration using scala

Just wondering if when creating a login/registration web page using scala is very similar when doing with PHP/HTML which I have used in the past. I've just decided to start learning scala and am a total beginner with no clue. With PHP/HTML, I would use a form, 'POST' method and then the appropriate my_sqli prepared statement insertion and selections. Is it similar or very different in terms of overall methods and way about going with it (obviously excluding the minor differences in syntax). How and in what ways is it different or similar? thnx
Scala is totally different from PHP. Finding connections between them is really hard. I would say that Scala is better in every way but bashing PHP is just too easy nowadays.
I would suggest you to give a look at Scalatra, arguably the most mature among simple web frameworks in Scala. Every framework works differently but you can get an idea of how you think and write code in Scala giving a look at Scalatra examples.
Also, if you never worked on a JVM, it will take a while before being able to properly develop logic in your code. There are many things to learn about the environment (and obviously about the language too) before being able to develop a web app. My suggestion is to first spend some time studying the language and only then begin approaching web development. If you need a language that you can pick up and start writing code, Scala is not the right choice.

Apache2 & eruby, as 10 years ago

Why can't I use eruby without Rails ? I don't like Rails, but it seems eruby has not been used without Rails for a decade (If I refer on the dates of the lasts questions about eruby on Stack Overflow).
Here are the lines that I added to my Apache configuration to handle .erb scripts :
AddHandler application/x-httpd-erb .erb
Action application/x-httpd-erb "/cgi-bin/erb-cgi.rb"
When I try to load a simple test page (located on myserver.fr/test.erb), I get the following error :
The requested URL /cgi-bin/erb-cgi.rb/test.erb was not found on this server.
It seems like Apache try to open "/cgi-bin/erb-cgi.rb/test.erb" instead of running /cgi-bin/erb-cgi.rb with test.erb as a parameter (what should be the normal behavior of the Action directive)
I don't detail here the /cgi-bin/erb-cgi.rb script, the server doesn't even try to open it.
It was working for the whole world 10 year ago, I don't think I'm doing something wrong... Am I ? (Of course I am)
And yes, I'm french, so there is a nonzero probability that my English is bad. Thanks for your help!
Not exactly what you asked for, but if you want easy templating in Ruby without Rails, you may want to have a look at Sinatra, a very lightweight framework build in Ruby.
Sinatra can be run in a single command, manages routes and templates, and that's about it.

Alternatives to CGI.pm for header() and param()?

I've been an avid user of CGI.pm since the previous millennium so I was a bit surprised when it disappeared from my old Ubuntu server when I upgraded it recently. My short-term fix was sudo cpan install CGI, but a quick web search to find out why it was missing in the first place revealed CGI::Alternatives which explains why it has gone and offers some suggestions for alternatives. For my purposes, HTML::Tiny looks best for replacing my programmatic HTML generation, but Alternatives is strangely silent on the subject of HTTP headers and CGI parameters.
I broadened by search and found lighter alternatives to CGI.pm on perlmonks where one response suggests CGI::Simple, but the recommendation is less than whole-hearted - "its not quite as up to date as CGI.pm".
So is CGI::Simple the way to go, or is there a better alternative?
Please don't spend time suggesting "rewrite everything using framework XXX". I really don't have the time or energy for that. I'm happy to replace all my HTML generation with HTML::Tiny, so I'm looking for something with a similar (or lower!) amount of rework to replace header() and param().
You're missing the point if you're looking for an alternative that provides header and param.
The argument for the removal of CGI.pm from core (but not from CPAN) is that you shouldn't have to deal with CGI yourself; you should be using a framework that handles this for you.
If you don't agree with this — if you're looking for an equivalent to header and param — go ahead and keep using CGI.pm.
If you do agree, CGI::Simple is no better than CGI.pm.
As others have said, there's no reason not to use CGI together with HTML::Tiny. So that's the answer to your question. For the last five years that I was using CGI, my programs all started something like:
use CGI qw[param header];
which is the approach you're talking about here.
If you wait a year or two, the plan is for the HTML generation functions to be removed from the main module, so your problems will all go away at that point.
But that's not what I'd do in your situation. I'd switch to using PSGI and Plack. You said that you don't want anyone to suggest a new framework, so I'm not going to do that. Plack isn't a framework, it's a toolbox for writing PSGI applications. Certainly, I'd use a framework like Dancer, but you don't have to. You can happily use Plack without any of the frameworks built on top of it.
You'll still get most of the advantages of PSGI. You'll be able to deploy your applications in any way you like. You'll have access to all the awesome Plack middleware. Testing your program will be far easier.
When you're using "raw" Plack, the equivalent of CGI::param is Plack::Request::parameters and the equivalent of CGI::header is Plack::Response::headers.
So there are three answers to your question.
Carry on using CGI.pm. Just stop using the HTML generation functions and replace them with HTML::Tiny
Use raw PSGI/Plack and bring your web development into the 21st century
Use one of Perl's many great web frameworks.
Unfortunately, you don't seem to like any of those answers.
The issue with CGI.pm is not that it's going away, merely that it will no longer be distributed as part of the core Perl distribution. However that doesn't mean you have to install from CPAN. On your Ubuntu system you can just do:
sudo apt-get install libcgi-pm-perl
and you'll be off and running with the same old CGI you know and love :-)
The correct answer to my question is that use CGI::Simple is better than use CGI qw(header param) because it loads faster.
Answers along the lines of "Use Plack, it's the future of Perl for websites" weren't helpful to me because I didn't have time to learn a new programming paradigm or to discover how to reconfigure my web server to make it work, no matter how insistent the Plack Evangelists were that I was wrong in what I was trying to do.
I've now had a bit of time to wade through the links to documentation and presentation slides I was offered and I can see what they were getting at, but one failing in what I've read so far is the lack of a concise end-to-end working example to help get my head around things ... so here's what I knocked together to get me started (and, no, I haven't finished yet!). I hope that others beginning the journey from CGI to PSGI will find this useful to help get them underway...
First you need to install Plack. I'm running an Ubuntu 14.04 installation so it was simply a matter of running sudo apt-get install libplack-perl. The generic way is to install Task::Plack from CPAN.
Next you need to know where your cgi-bin directory is located. You ought to know already if you're a CGI die-hard! Since I'm running Apache mine is defined in /etc/apache2/conf-available/serve-cgi-bin.conf by ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/.
Now for the magic. We're going to create a CGI script that runs a PSGI app, handing it data from the CGI environment. This is good for experimentation and testing but NOT for deployment, as you don't get any of the speed benefit that PSGI can give you (for that you need something like Plack::Handler::Apache2, Plack::Handler::FCGI or mod_psgi in Apache, or a dedicated PSGI server such as Starman or Starlet, or one of the other handlers mentioned on PlackPerl.org). Create /usr/lib/cgi-bin/psgi-cgi.pl with the following contents and make it executable:-
#!/usr/bin/perl
use Plack::Util;
use Plack::Handler::CGI;
my $app = Plack::Util::load_psgi($ENV{PATH_TRANSLATED});
Plack::Handler::CGI->new->run($app);
Next we need to tell Apache to pass PSGI app files to this handler. I did this by creating /etc/apache2/conf-available/psgi-cgi.conf containing:-
Action psgi-cgi /cgi-bin/psgi-cgi.pl
AddHandler psgi-cgi .psgi
then loaded it into my Apache server by running sudo a2enconf psgi-cgi and sudo service apache2 reload. Basically you need to get these lines into your httpd.conf file and restart the server.
Finally, my first PSGI script, which I created in my server's DocumentRoot as /var/www/html/hello.psgi:-
use Plack::Request;
my $app = sub {
my $env = shift;
my $req = Plack::Request->new($env);
my $par = $req->parameters;
return [
200,
[ 'Content-Type', 'text/plain' ],
[ "Hello world!\n",
map("$_ = ".join(", ", $par->get_all($_))."\n", sort keys %$par),
]
];
};
The application is a coderef which returns a 3-element arrayref: the first is the HTTP status code, the second is the name,value pairs for the HTTP header, the third is the body of the response (which could be generated using HTML::Tiny for a web page). The first 2 elements answer the question of what you need instead of the CGI::header function - nothing! (though for more complex handling you'll need Plack::Response::headers). The example also shows how to replace CGI::param - use Plack::Request::parameters, which returns a Hash::MultiValue object containing the values of URL (GET) and BODY (POST) parameters, including the ones with multiple values.
Finally, a test:-
$ wget -q -O- 'http://localhost/hello.psgi?a=1&a=2&a=3&b=1&b=4'
Hello world!
a = 1, 2, 3
b = 1, 4
I hope this is useful to other CGI die-hards in taking their first steps towards PSGI proficiency, and I hope the Plack Evangelists will acknowledge that it takes a lot of reading and comprehension to get even this far.
CGI::Minimal would a good option, it is much lighter than CGI & CGI::Simple, but it lacks advanced methods like CGI & CGI::Simple

When to implement logic in the front-end vs the back-end?

So I've gotten very familiar with Javascript MVC's over the past few weeks. Now I'm looking to learn the how to program a backend(specifically using asp.net MVC's implementation). I'm learning about the razor's view engine etc.
One learning block I'm running into when reading up on examples and tutorials is that I am thinking to myself "well..can't I just do that in the front-end with javascriptMVC" for most of the logic, and If I need to talk to a database I can just use a JSON call. There must be some value in back-end coding but right now I don't see it(hoping to get that solved).
The client is always exposed to attackers, hence you can never trust the code.
In other words: Any security-related things, verification and validation logic belongs to the server, all authentication and authorization stuff, … and: when you need to make sure that there is one reliable instance to decide some things, e.g. on prices, discounts, and so on.
There is a saying in web programming, and that is: All input is evil.
So whatever comes from your frontend (which basically is your JavaScript application) should be handled with care. Always black- or whitelist input, encode it, transform it, check it, and so on … and the only place where you can do this reliably, as it's the only place that is under YOUR control is the server.
Moreover: Never put secrets into the client, such as credentials (for your database, e.g.).
Hope this helps.

Pure PHP/HTML views VS template engines views

I would like to know which approach is faster, using the pure PHP in the HTML files or using a template engines like Smarty,Twig, ...
What I would particularly like to know is next: which is parsed faster, is the Smarty cache for example faster than using pure PHP?
Which of the template engines is the fastest? I'm about to rewrite simple application where speed is on the first place.
"Depends" is the answer to all your questions.
What is "faster"? Execution time? Development time? Maintenance? Memory overhead? A mixture of them? A template engine is usually trading in some performance (speed, memory) for better development and maintenance.
If you are talking about purely dynamic templating (meaning: template evaluated on every request) PHP will outrun any template engine. This is a nobrainer, really. If you're taking caching into account, a template engine like Smarty may help. Caching is nothing you couldn't implement yourself in plain PHP, though. With Smarty it's just been done for you (and on a far more sophisticated level than you possibly would).
If you are using a framework, say Symfony, it might be wise to use Twig, as Twig and Symfony are tightly integrated. Sure you can use Smarty or plain PHP. The question here is: is it practicable?
Caching makes sense when building sites from datasources like a database or remote APIs. What you are really saving (in a sense of reducing) here are database calls, intensive calculations, etc. Check if you have any time-intensive functions running to build your site. If so, use caching (if you can).
Knowing development/maintenance/convenience/performance trade-offs, I would (always) recommend using a template engine. Being a Smarty developer, I'll, of course, suggest using Smarty. That is unless you're using Symfony, then you might be better of with Twig. Or some other framework featuring some other template engine.
Please ignore posts like Smarty vs. Twig, as they only compare a very limited view of the engines. Don't trust benchmarks you haven't faked yourself™.
In general, though, Smarty 3.1 is a bit faster than Twig. Twig is doing a lot of stuff at runtime (being the time when a template is executed) that Smarty does on compile time (being the time when a template is prepared for execution). Twig is not really pissing away speed here. Twig needs to do certain stuff at runtime by design. They traded a bit of performance for a bit of "convenience" (Accessing arrays and objects with the same notation, for example).
Let's tear the tropes related to this subject apart:
1. Keep logic out of the presentation - Do not put 'code' into your HTML
Anyone who says this and then tells you to go with templating is contradictory:
PHP is an interpreted language - it becomes C code on execution.
The templating 'syntax' is interpreted into PHP
They must stop lying to themselves. Their 'templating syntax' is a programming language built on top of another, which in turn is built on top yet another language - That's inefficient, redundant, and weird.
Furthermore, I fail to see how the very existence of the variables every templating engine that ever was depends on aren't considered logic - Their existence, content and implementation depend on a logical backend.
And what of those templating systems with if/else statements and for loops? That's the very essence of logic - The very concepts which most programming languages utilize. They require variable data which can only be generated or exist through some form of computation.
You cannot serve dynamic content without mixing presentation with logic. It's impossible.
2.1 It's safer...
So, you don't trust your HTML guy?
Case: You think your HTML/CSS guy is stupid and will accidentally print the database password
If that's so, I've got news for you - Your environment is already not safe if sensitive data can be accessed/modified from anywhere within the program.
Case: You think your HTML guy will print random server constants - it's dangerous to allow him, as an individual, to work with server logic
I see - He's either stupid, or hates his job and wants to be fired and therefore will do something dumb like printing session variables. Fine, but to that I'll say...
...Why the heck is this stuff not peer reviewed? Even if he had no access to direct server logic but rather a fancy templating system, he could still equally spread his his stupidity/hatred merely because he has final say on output. Or, he could even be in cahoots with another programmer (If any) and still access server constants and co.
-
2.2.1 Good templating engines automatically sanitize output, or allow the templating-guy to do it himself - he knows better when data should be sanitized
You dummy.
You don't know when output should be sanitized? You couldn't do that yourself..?
Even so, maybe you're just the code monkey and the HTML guy is a web-security HTML-injection specialist, and he should be the one sanitizing output. In that case, giving him access to PHP also allows him to use the likes of htmlspecialchars() rather than whatever the template gives him to do the same thing.
Regarding automatic escaping, provided you're safely passing along content, you can implement such a simple feature within the code you're doing so.
--
2.2 ...and I can control what data is being worked with
Think about classes, functions, etc - You throw data in, they work with it, then you get a result. Typically they do not deal with outside data unless it is handed to them (Doing otherwise is unclear, dangerous and bad practice - Some constants aside). Through these same methods, you can pass on precisely what you need to your output in an efficient, clear and unlimited manor.
--
All that said, it seems like the reason you think your templating engine is any safer than plain code is because you're lacking in several areas of general safety:
You (Or whoever) do not peer review content - You allow individuals to output content.
You are not implementing proper or safe programming practices, and seem to not realize that you can control what's passed along from point A to B.
3. PHP syntax is too hard/difficult to teach the style people
The truth is it's no more complicated than the psuedo-syntax created by template systems such as Smarty, so if this is an issue than dynamic content isn't for you.
The following is in PHP 'short syntax' - Is it too difficult?
<div class='username'><?= $username ?></div>
4. It's too much work to develop my own solution
Though I'd argue it's not, you're free to choose whatever you wish! Choose whatever fits your needs best. They're usually free, not difficult to integrate, and come with loads of features out of the box.
I'm under the impression that most people opt for templating simply because it looks 'neater' within the file - They love thinking that the TPL file is some special thing they created, they like the way the syntax looks; As if by some magic, the variable is 'called' by the little # or # symbol and hops from your logic into the output.
It seems like a trick - The beautiful enchantress (AKA The templating engine) draws you in with her beauty. Though she's appealing to the eye, she's really a blood sucking demon and extracts your soul (Server resources) in exchange for eye candy nobody else sees (Your users would much rather have a faster website and more features funded by the $$$ you're saving on power/server renting)
<title>{{#title}}</title>
Vs
<title><?= $title ?></title>
I will admit, there's only one case I can think of in which templates have any ground over PHP - Portability to other applications. appartisan's answer addresses that. Even so, it's not hard to replace <?= $var ?> with {{#var}} - That's a job for a templating-esque system.
Simply and purely opinion, I think the only advantage is portability. You can re-use templates or views from a template engine into other backend application. Say you're moving your application from PHP to Java, you don't need to refactor the templates.
Otherwise, you're adding complexity, adding other layer of execution ( more time ), more requirements to maintain the application ( you need people that knows that template engine ), and so on. PHP itself it's the best and more featured template engine you're going to get, probably the fastest, and you can do caching also, with the advantage of controlling cache from the backend application, and not from the view.
I will take up this again as things have changed significantly and there are some pieces of evidence missing from the earlier answer.
Without getting deep into why frameworks use template engines over PHP which most do. For some reason there is a constant effort to "fix" PHP with another abstraction layer. Always with claims of simplicity without loss of versatility or performance.
Regardless, the use of PHP is still the fastest and most versatile way of templating. PHP in it's earliest incarnations looked much like a templating language. But let's take a look at the advancements in PHP and place them side by side with the after layers.
Twig and some others claim caching something which was always an addon in earlier versions of PHP. Caching is now a default part of PHP5.5+ (Opcache) and so using PHP as a template language will give more performance enhancements.
Twig and others claim simple syntax for designers. In comparing the syntax of a template engine you'll see that the logic is similar with the only benefit of using a template system like Twig being another layer of security separation between the designer and the underlying system code.
Two very popular CMS Wordpress and Drupal used PHP as their template engines. So the old argument of using a template engine to secure and simplify the use of PHP while designing a website is not really valid in today's web. While Drupal 8 is moving on to Twig it mostly because twig is part of Symfony Framework ( returning to why do frameworks use template engines). Wordpress on the other hand is still using PHP. As Wordpress is growing by leaps and bounds with web designers using PHP to help this happen. Drupals Community has also been split in part by decisions to use Twig and Symfony.
So it would seem that using PHP is the better choice in terms of performance but also the preference for themers and designers going forward. At least all evidence leads to this conclusion.
That being said here's my baseless opinion. I think that using anything other than PHP as template engine in today's web covers some inherent weaknesses in the underlying framework or web application architecture. That weakness being its complexities and complications that cannot be explained easily at the designer or themer level.
If you are writing a lightweight application that has to be small. Keep it small and performing optimally by using PHP and leave the other engines to "enterprise" level groups and projects
I have a problem with the argument that logic and data display must be separared as much as possible. I found that data validation and display actually requires a lot of logic on forms. Information about data type, number range, relation between different data requires a lot of code. The real question is should we use a template language on the server side or Javascript on the client side. By using Ajax and client side code for data display and validation, I end up having very little template code. The biggest problem with template engines is the intoduction of new code rules and syntax. I see the future with PHP, Jquery and Ajax and template engines loosing its appeal.