Workaround to dynamically load CSS resources

I have been struggling for a while to find a way to dynamically load CSS resources in a coherent and reliable manner. As I am working with dojo on my current project, I started with using its event connectors for a classical approach: creating a DOM link element with the desired CSS resource and adding it to the document’s header programmatically.

?View Code JAVASCRIPT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
function getCSS(filename){
  var fileref = document.createElement('script');
 
  fileref.setAttribute("type", "text/javascript");
  fileref.setAttribute("src", filename);
 
  var handleLoad = dojo.connect(fileref, 'onload', function(evt) {		
    console.log('the element ' + evt.target.src  + ' loaded');				
    dojo.disconnect(handleLoad);		
  });
 
  var handleError = dojo.connect(fileref, 'onload', function(evt) {		
    console.log('the element ' + evt.target.src  + ' failed loading');				
    dojo.disconnect(handleError);		
  });
}

Continue reading Workaround to dynamically load CSS resources

Why iframes in rich web applications are evil

I write this post claiming to heavens that you (as a web developer figuring out whether to use or not iframes) will read and follow my advice. Not only for me, nor for you, but for a better world.

Let’s say you are in charge of porting a desktop application to the web environment; you have to change the paradigm and start using CSS, JS (lukily even a framework like Dojo) and finally HTML. Your webapp has menus, submenus, a lot of stuff and many different forms, interfaces and views to present and collect the information to and from the user.

And at some point you discover what iframes are, and may you think “they might well pay the effort, I can create every single interface separately and finally integrate them into the full framework, like a puzzle”. Don’t. They are not worthy, and you’ll find out why too late. Seriously, while iframes are useful in some practical situations (when there is absolutely no other solution), they bring in some major drawbacks when used to build the interfaces of your rich web app:

Continue reading Why iframes in rich web applications are evil

E/R Zero or One to Many relationships

While 1:n, 1:1 and n:m relationships are thoroughly used to design logical database models, there another another kind, {0|1}:n that may come in handy in some cases. Lets analyze this relationship carefully.

Imagine a relationship between students and classrooms. Every classroom can have N students, meaning this zero, one, or many pupils. From the other side, every student must have a classroom, otherwise she won’t be allowed to study. This is a classic 1:n relationship, used in most of the real cases that we may encounter.

But what if, let’s say, a student had finished her studies and, however, wasn’t deleted from the database? (just to keep the records and other sensible information). In that case, the statement ‘every student must have one and only one classroom’ would be wrong. Instead, we could say ‘every student can have one classroom or none’. Now we are talking about zero or one to many relationships.

Continue reading E/R Zero or One to Many relationships

Don’t forget the (web) interface

As a web developer, I am normally more into the back-end stuff: PHP, MVC, performance, page generation time, queries optimization and such stuff. However, it is a good idea not to forget the big picture (which is something that I tend to, by the way): server-side performance and stability are critical, but the client-side interface (JS, DOM Events, etc) plays also a significant part when talking about loading time, server load and overall performance.

In these times where cloud computing has settled and means to stay, it is very likely that our web interface is going to use several toolkits, libraries, widgets, plugins from different frameworks (such as jQuery, Dojo, Mootools), which, if used out of a coherent system, will produce a lot of server calls to download the related resources. Not only this adds up to server load, but it also can increase total load time by several magnitudes, which, in turn, makes the user feel that the entire web application is slow and crappy.

Just a few details we should never forget when optimizing our web interfaces to avoid the effect above (and this goes more as a self-reminder than as a hint):

  • Use the right headers so that your image, CSS and JS files are kept in browser’s cache.
  • Make sure that gzip compression is active on the server.
  • Minify the JS/CSS files before putting them in a production environment.
  • Use sprites for GUI pictures.
  • Use a dynamic loader that grabs the related resources on-demand and asynchronously.
  • Combine JS/CSS files into modules.

There are, of course, many more things you can do to ensure that your application runs smoothly, but the ones above are relatively easy to apply, and produce results in the middle / short term.

Any suggestions? Comments are welcome.

New MVCLight v0.1a released

I have had the time lately to build a basic MVC framework in PHP, based on the great tutorial by PHPro.org.

It has been designed to be light though structured and functional. It is intended for people who need to develop home-brew solutions and are not happy with the footprint of other frameworks, or for those who just want to have fun while creating their own MVC system.

If you are interested, visit the page for documentation and download here.