I'm really enjoying working with Qcodo on my latest project, but I think there is at least one way that it could be substantially improved.
Just like ASP .NET, Qcodo uses objects to represent controls that can perform various server side or ajax actions. Just like ASP .NET, it uses inline javascript to achieve this, and includes an arbitrary number of scripts and style sheets at render time.
Unlike ASP .NET, we can feasibly do something about it!
I could see using Qcodo in the future, and I would not mind implementing the changes I'm about to describe, but I would like some buy-in from the project leader(s) first.
First, it's admirable that you've undertaken to write all your own javascript, but I think the project would be better served by using an existing javascript framework. Even if Qcodo had strong javascript hackers working on it, a popular framework has the dedicated community that Qcodo's UI code could never have. I've used a lot of frameworks, and I feel comfortable saying that JQuery is the strongest for several reasons:
1) It's very simple to use
2) Very clean syntax
3) Excellent documentation,
4) Excellent code (that we can modify if necessary, and check in to their repository
5) Very active community
6) Accessible project leads
7) Corporate buy-in on several fronts. Google uses it, the JQuery UI guy Paul Baukus is now working on JQUI full time because he has corporate sponsorship. The list goes on.
8) It does what I need it to do (read on)
The two major client side issues Qcodo faces can be solved by the same architecture. The first issue is multiple script includes. On any given page there are at least 5 script includes within the Qcodo main form without counting any additional, user-defined includes. For professional work, on applications that must perform, this is unacceptable.
Each include costs 200ms of additional overhead if the net isn't congested, and they are included at the TOP of the Qcodo form. “Of course they are, how else will the subsequent calls use the functions declared in the file if they aren't at the top?” I have an answer for that, but before we get there, here's a fun fact:
Script includes are downloaded synchronously.
That means that if you have 5 images on your page, they can download at more or less the same time, because they are asynchronous. If they are the same size, they will all be ready in approximately the same amount of time as if there were only one (not quite true, but close).
If you have 5 scripts, they will download ONE..AT..A..TIME, and they'll stop everything afterward from downloading until they are finished. I just checked one of my pages in the app I'm working on with a traffic analyzer, and what I'm saying pans out almost to the millisecond: those script includes add at least an extra second to load time. That's a big deal when you're working on an app that needs sub-second load times.
The second problem: all those inline javascript lines have to be evaluated as they are hit as well, slowing down render time further, not to mention being horribly ugly, and inflexible when you need multiple events on a given control, or events that span multiple controls.
Those are the problems, here's the solution:
Right now the script includes are rendered at the top of the qcodo form as part of the RenderBegin call, and each control is responsible for rendering its own javascript. I propose that we create a facility that acts as a sort of javascript registry. At any point, like in the prepend, or in a specific form class, a programmer can write:
QApplication::$ClientScripts->Register('my_script.js');
Hard coded into the framework, on app initialization, all those 5 scripts that are currently included separately (if they still exist after the changes), would be registered just like above. It would look in the current assets/js folder for the scripts specified.
Also, instead of each control rendering the javascript, it would simply call:
QApplication::$ClientScripts->RegisterEvent($myQEvent);
This $ClientScripts would keep all that information until the RenderEnd() was called. That call would fire $ClientScripts->Render();
That render call would first take all the registered scripts, and pull them into one file together. Then it would take all the events and render those:
Here's an example of what a postback on a listbox might look like using jQuery:
$('#lstBoxId').onclick($.ajax( ...args... ));
That's it, it's beautiful, it's simple.
After that, it would minify the javascript on the fly, then when the new file is rendered, the addition to the markup is:
<script type=“text/javascript” src=“js.js”></script>
Just one dynamically loaded file, at the bottom of the page, with all the qcodo scripts, all the custom scripts, and all the event information for the whole page. It could be easily cached to prevent having to create the file every time.
This alone would pull the framework far out in front of others, in my mind. It's not a difficult change to make, it's a day or two of work. What do you think?