Med fokus på din virksomheds forretningsgange watermark with eaktion circles

Posts Tagged ‘YUI’

Templating with Smarty for Ajax Enabled Applications

Thursday, August 18th, 2011

JavaScript is the future

The future is pretty clear to me, JavaScript will be the one and only on the web.
And I mean both on the client side and the server side. Am I going crazy?
Just wait for node.js to be ready for prime time and let the YUI Library be finished with the application framework, then we start talking.

However, while we wait for the day of the grand merging of technologies, we still have to do some work and keep the code nicely organized. Smarty helps me to do that. I use Smarty templates to separate code from presentation and (among other things) Smarty plugins to organize my code.

In the meanwhile, get YUI and AJAX to work nicely with Smarty and PHP

When I started using Ajax it was with the help of Xajax. What I like of Xajax is that it allows me to target a single function right from the client code, and to control the JavaScript code from inside the PHP code. A pretty fine grained 2-way communication.

Now that I use YUI more and more, I wanted to get rid of the duplication of JavaScript code that is caused by having to load both the Xajax and the YUI JavaScript libraries. Anyone serious about JavaScript would have no doubt, I had to say goodbye to Xajax.

However, YUI is naturally slanted to the JavaScript side. With YUI you produce modules and stuff that encapsulate XHR transactions, and you pass a url to the transaction. On the server side you’re on your own for how to organize your code in a manageable way.

Manageable to me means among other things that:

  • I can include my php files from wherever I want, especially from outside my server root
  • I can have a one-to-one relationship between the page I’m showing to the user and the code that supports it
  • I don’t need to create extra urls just to pull in responses to my JavaScript code
  • I don’t have to reinvent a new set of conventions each time I write some JavaScript code

These are the things I felt YUI was making difficult to me.

To make up for this I’ve developed a set of two modules: inlineXHR(php), a lightweight PHP module, that works together with inlineXHR, a lightweight JavaScript module for YUI 3. With the two inlineXHR modules, I have re-established a fine grained 2-way communication between my PHP code on the server side and my JavaScript code on the client.

Now I can again target directly from JavaScript, PHP functions, class methods and Smarty plugins. All AJAX / JSON stuff is taken care of once and for all, the cursor is spinning when it has to, errors are logged to console or popped up in alerts, and I can write PHP code without even thinking about the fact that the output has to be sent through the wire, as JSON.

If you use YUI and PHP, and you too think that life is too nice to use time reinventing the wheel each time a JS code need to talk to your server, you might want to give it a try. It’s free, open source and BSD licensed.

Click to see usage instructions and working examples

SliderWindow – a YUI based widget for communication to the user

Wednesday, August 6th, 2008

As of yesterday we have released a new widget: SliderWindow.  This post is to explain why and how it is to be used, and to be able to receive comments from you, so don’t be shy, post your comments. The comments are moderated so it will take a while before they appear on the blog.

You can see it in action here.

Why a new widget?

The Ajax style of application has removed the typical browser behavior of posting to the server and reload of a new page. It was a nuisance for many reasons and we love the fact that it is no longer there, however this behavior also provided the user with several clues about what was going on. At least two:

  1. something has been sent
  2. something has come back

In an Ajax application we usually provide a spinner, or a time glass cursor, to signal that we’re waiting a response from the server. When the action has updated something some other visual clue must also be provided to notify the user of what has actually happened:

  1. If you delete an item, that item might have to be greyed out on the screen, or removed in a noticeable way.
  2. If you edit an item you edit it on the screen, and to be sure that the server actually has received and saved your changes something more than just your changes on the screen must be sent back and shown to the user, whether it be an “OK”, “item saved” or a color transition of some fixed item on the screen.

Ok, we do this, what’s the problem then, one could say? The problem is that in a complex application the user receives:

  1. A great quantity of feedback messages
  2. A great variety of feedback messages

1. Great quantity

The sheer amount of situations in which the user needs to get a simple “OK” from the application requires that you have a dedicated area on the screen for this kind of messages. Pop up messages that require a click or enter by the user are of course a no go. However your “OK” must disappear or change colour after they have been displayed, otherwise the user won’t know which “OK” is which.

2. Great variety

In my experience the application needs to send to the user a fair amount of different kind of information, in many different situations and to different purposes.

The first instinct of the developer (er.. well, my first instinct)  is usually to device something specific for each of these situations, but one ends up with the “usual” mix of good and not so good solutions for each individual case. This disadvantage is, that no matter how perfect each of these solutions is in each particular case, they are different from what happens in any other case, and this, for the user, is in itself a very bad thing:  the user needs to know what to expect in different situations that, by the way, might not seem so different to her/him after all.

Especially this second aspect urged me to device something that:

  1. did not take up too much space on the viewport;
  2. could easily and always be noticed by the user;
  3. did not necessarily require an action from the user;
  4. could be controlled in a way to enforce some action from the user, in situations where this is mandatory;
  5. could display any amount of information;
  6. could keep this information available for the user to retreive it at her/his convenience;
  7. had a fairly predictable behaviour;
  8. should be working with YUI.

I believe that with the SliderWindow I have reached these goals.

How to use it

When the SliderWindow is installed (see the easy installation instructions and examples ) you can always call it from the application and publish a message inside it, whereby the SliderWindow :

  1. will slide open and close within approx. 1 sec, OR
  2. will slide open and remain open until the user closes it
  3. can be clicked open by the user, clicking on its 5 px thin, visible right border, OR
  4. can be opened by the user, hitting Ctrl-right arrow
  5. can be closed by clicking the close icon or by hitting Ctrl-right arrow

If your message is just a “OK” or “Order xxx is updated” or even kind of “The new order has got no. xxx. ” you probably will want to open and close the window right away. It’s routine messages.

However if your message is something like: “The added student has has no available allotment and won’t be able to receive books, unless the allotment is updated”, where this might be an unusual situation and still a legal one, you will probably send the message and leave the window open, to be sure the user has seen the message.

In the end your users will tell you which messages they want to be forced to acknowledge. In general they will want to be forced to acknowledge messages, that require them to do some physical action, ie. checking something on a paper file, verifying the functionality of some machine, retriving some item from a depot  or similar things. What specifically will depend on the company business routines and level of on-line integration/automation.

For system errors or user errors we don’t use the SliderWindow and make use of a YUI dialogue with a red header. This requires always a click to be closed, and marks a clear difference from this kind of messages.

Well, thinking about this, a possible improvement could be to add a method to control the color of the window and send error messages to the SliderWindow too, taking care to change the color of it, and leaving the window open. What do you think?

Requirements and some tech info

SliderWindow requires some YUI files, and only one .js and one .css additional file (plus assets directory for the  3 images). It is an extension of the YUI module that has pre-applied a container effect object to create the sliding movement. It is released under a BSD licence.

If you want to change the color of the window just add 3 new images for header, handle and footer and add your css file to override the paths for these 3 images. Currently you need to respect the same size though.

Go to the installation and example page and/or leave a message.