Tuesday 27 November 2012

Interesting thing coming in ECMAScript 6

Javascript always has been the poor cousin to all that whizz-bangery that happens on a server and as a result anything new coming down the pipe line kinda gets lost in the news-stream of super-duper server improvements.

I try were possible to keep up to speed with what's about to come along and it was with this in mind I I was casting my eye over Juriy Zaytsev's EMCAScript 6 compatibility chart and I started to notice green's appear. Some of the current or beta versions of the browsers are starting to support the new V6 changes so it shouldn't be that long until we start to see them in the wild and can start to use them in anger.
(if you are interested in the EMCAScript 6 Draft Doc you can download it here)

Of the changes coming I am piqued by the idea of

1. Modules

While there are some JS libraries that do something very similar ES6 will provide support for modules, the rational behind this is to provide for:
  • Standardized mechanism for creating libraries.
  • In-language loading of external modules (non-blocking, direct style).
  • Portability between different host environments.
  • Future-proof mechanism for platforms to introduce experimental libraries without collision.
  • No installation/registration code within modules.
As Modules are static by default (but can be dynamically reflected) this makes them far more compatible with static scoping. Modules are loaded from the filesystem or network in direct style instead of by callbacks and this means the main thread of execution is not blocked by the load.

It is hoped that Modules will be used for scoping and their implementation preserves and promote static, lexical scoping, thus avoiding the many problems of dynamic scope: programming pitfalls, malicious scope injection, poor performance and  lack of modularity. Static scoping is also necessary for checking for unbound variables at compile time.

A simple module would look like this

module orders {
export function ASP(qty,val) { return val/qty; }
export var dollar = "$";
export var pound = "£";
}


This module would then be accessed in your JS code like this :

import orders( ASP ,  pound) from orders;
alert( pound+" "+ASP(ThisOrder.Quantity,ThisOrder.Value) );


I can see instances where this will be very useful!

More details on Modules can be found here

2. Object.Observe
Object.Observe gives us the ability to watch Javascript objects and report back changes to the application, changes like properties being added, updated, removed or reconfigured. When I am building a UI frameworks I often want to provide an ability to data-bind objects in a data-model to UI elements. A key component of data-binding is to track changes to the object being bound. Today, JavaScript frameworks which provide data-binding typically create objects wrapping the real data, or require objects being data-bound to be modified to buy in to data-binding. The first case leads to increased working set and more complex user model, and the second leads to siloing of data-binding frameworks. ES6 will get around this by providing a run-time capability to observe changes to an object. Here is interesting discussion on this soon to be available new feature

3 Default Parameter Values

Default parameter values allow us to initialize parameters if they are not explicitly supplied, so you can do things like


function dspInputPanel(footer = "Steve McDonagh")
{
       ... build inputPanel Object..
       footer.innerHTML = footer;

}

So when I call dspInputPanel() with no parameters the footer object will contain Steve McDonagh
if I call dspInputPanel("Anne Other") then the footer object will contain Anne Other

4. Block Scoping
There will be 2 new declarations available for scoping data in a single block

let which is similar to the var declaration but allows you to redefine a var in the let's block scope without changing the orginal var in the scope of the function

function doInterestingStuff()
{
         var x = 5;
         var y = 6;
         let (x = x*2,y =y*3) { alert( x+y ); }     // pops up 28
         alert(x+y)                                            // pops up 11
}


const is the other declaration and is like let but is used for read-only constant declarations

5. Maps
Arrays of Name - Value pairs have been around a long time in JS and ES 6 will introduce the new Map() object with it's functions SET(), HAS(), GET() and DELETE() that makes using them even easier

var myDogs = new Map();
myDogs.set("Fido","Poodle")
myDogs.set("Rover","Collie")
myDogs.has("Fido")                                 // Returns true
myDogs.get("Fido")                                 // Returns "Poodle"
myDogs.delete("Fido")                             // Returns true when deleted
myDogs.has("Fido")                                //  Now returns false


6. Sets
SETs are basically arrays and there is a new object creator Set() with associated methods HAS(), ADD() and DELETE()

var myCustomers = new Set( ["IBM","DELL","APPLE"] )
myCustomers.has("IBM")                   // returns true
myCustomers.add("ASUS")               // adds "ASUS" to the set
myCustomer.delete("IBM")                // Removes IBM from the set
myCustomer.has("IBM")                   // now returns false

This will allow array filtering to be so much easier, consider the following where I have an Array of customer names that I want to ensure is unique this new method is much much much easier to read.

function unique( customers )
{
       var ucust = new Set();
       return customers.filter(item) {
                                     if(!ucust.has(item)) { ucust.add(item) }
                                     return true;
                                     } 
}



There are loads more changes and improvements in the spec and it seems that ES6 is targeting a 2013 full spec release but as always some browsers are already implementing individual features and it's only a matter of time before their availability is widespread.

JS it seems may be coming out of the closet in the next 6 months and may soon be considered a "proper" language :-)

Friday 23 November 2012

The new CSS3 @supports() rule is really rather cool!

As all devs know , browsers can in varying degrees be a right royal pain in the arse when it comes to standards compliance and when you throw in companies like Never Upgrade a PC Till It Breaks Inc. who are still running XP with IE6, planning your super duper new web site to support them can be fraught with problems.

Most of us are used to the idea of designing a UI that degrades into a DBA-UX  (Different But Acceptable User Experience) to do this we have to be able to work out exactly the support for each feature that use in our design and have some "alternate" view that we can switch to.

Up until now I have relied on the wonderful Modernizer.js which smooths out a lot of the inconsistencies between browsers particularly the older rust buckets that NUPCTIB Inc use.

However there is a new CSS rule that will also help you - ladies and gentlegeeks let me introduce @supports() which has the syntax

@supports <supports_condition> { /* specific rules */ }

@supports is supported in most of the current browsers but as you might expect IE has ignored it and Safari doesn't have it yet. If you do use it in your CSS and a browser loads it that does not know what @supports is.. it will ignore the enclosed block, so you can still use your normal methods.

Basically what @supports() does is , it queries the CSS engine for support of whatever it is you need and then invokes the enclosed CSS rules accordingly.

@supports (display: table-cell) { /* some table-cell css in here */ }



Will test the CSS capability for box-flex and apply the rule if it is supported
You can also use a negative test for a rule not being supported.

@supports not (display:table-cell) { /*cope with non support CSS here*/ }

... and you can string together logical NOTs and ORs!

@supports (display:table-cell) and (display:list-item) { /* CSS goes here }

I am sure you get the idea and can see the usefulness of this addition to the Designer's toolbox


 






Thursday 22 November 2012

Useful i5/OS tip - Displaying Locks on an IFS Object

I was plagued this week by an odd problem on one of our i5 boxes. I was trying to use the CPYFRMIMPF & CPYTOIMPF to pull in data from a new Japanese division that uses nothing but Japanese characters in their data. This of course means UTF-8 / Unicode data, which can be a bit of a pain to set up in a DB2/i5 data table (particularly if someone forgets to make fields something other than CCSID 65535!)

Anyway.... I could get data off the system using the CPYTOIMPF into the IFS no problem at all, DBCS to UNICODE worked like a treat and everything was well with the world ... BUT ... try as I might I could not get CPYFRMIMPF to bring the data back into the DB2 file again.

There was a rather odd CPE3025 message that  told me the input file or path did not exist (error code 3025) and yet there is was, I could open it, read it, edit and save it  and everything seemed perfect .. but time after time I got the CPE3025 error and no data was transferred. I tried all day with no sucess and eventually went home hoping that a nights sleep would clear the mind and inspiration would come in the morning.


This morning came in an did a CPYTOIMPF which worked fine, did a CPYFRMIMF .. and .. it worked perfectly with no errors
After a bit of experimenting the culprit was discovered to be the fact that I had opened the file using Operations Navigator and even though the file had been closed normally Ops Navigator holds a lock on the file until Ops Nav is closed, the net effect of this is that the file is unavailable for the CPY* command.

Part of this analysis used a rather useful but lesser known API that you can use to track locks on objects in the IFS .. the api is this :

CALL QP0FPTOS PARM(*LSTOBJREF '/ifspath/ifsfile' *FORMAT2)

You need to have the *SERVICE special authority and the api dumps the locks to a spool file.

Easy when you know how but not an obvious tool for this particular problem





Thursday 15 November 2012

Domino Dander for Dosh 2013

Gentle readers some non-techie news!

The bold Eileen Fitzgerald and myself are planning a Dander For Dosh in May next year.

Eileen and were joined by the indefatigable Carl Tyler for 2012's walk along the coast between Bray and Wicklow in Ireland. We didn't pester the life out of you because we didn't get the giving organized in time for the actual walk. This year we will get our act in gear and start demanding money with menaces in January - You have been warned!

Conscious of the fact that the world is a tad short of cash we felt that we needed a real challenge one that would stretch us physically and encourage you to part with your hard earned cash. We are still discussing our options but top of the list is "The Great Glen Way" from Fort William on the West Coast of Scotland to Inverness on the east..80+ miles at around 20 miles a day for 4 days.

As plans form there will be more posts and many many requests for cash however if anyone would like to join us for 4 days of walking the length of the Great Glen under Ben Nevis along the edge of Lough Ness and down into the "granite" city, drop me a line and I will add you to the distribution list for our detailed plans.

Eileen and I cannot guarantee you good weather, but we can guarantee you four days of eclectic conversations, beautiful views, good food and good company (as you would expect from a group of Domino Geeks) I you want to join us for one day, two or all you will be very welcome (mainly as Eileen knows all my jokes and craves new material)


So Watch this space , marvel at our foolishness and when the time comes sponsor us as much as you can!

Sunday 4 November 2012

Alternates to the evil EVAL() in javascript

I am interrupting the Design Series of post for a quick JavaScript post that comes out of a question asked on the JavaScript forum on LinkedIn about alternates to the eval() function in JavaScript.

The most pertinent reasons for not using eval() are:-

1. Security - it leaves your code open to a JS injection attack which is never a good thing
2. Debugging - no line numbers which is a PITA
3. Optimization -  as until the code to be executed is unknown, it cannot be optimized.

Sadly EVAL is way to easy to use and as a result we see it all to often in places we shouldn't really see it and this can leave the door open to some nere-do-well making a mockery of the rest of your obviously wonderful code.

So what to do to avoid using eval()? Well alternates to the the 3 main areas I have used EVAL in the past are listed below.

1. When working out a bit of an object to change for example something like this

eval('document.'+IdName+'.style.display="none"');

Now I am not suggesting anyone WOULD do this given the tools available but I have come across code like this in older applications written by people just starting out in the wonderful world of JS.

document[IdName].style.display= 'none';

or

document.getElementById(IdName).style.display='none';

are both much safer and a lot faster.

2. Getting JSON that has been returned by AJAX calls to the server into the DOM, like this snippet of jQuery is doing.

$.ajax({ url: "getdata?openagent&key=SMCD-98LJM",

              success: function(data) { eval(data),
                                        doSomethingInteresting()
                                      }
        })

This will work but a more satisfactory way would be to use the JSON data type in the ajax call

$.ajax({
  url: url,
  dataType: 'json',
  data: data,
  success: *callback*
});

alternately use the $.getJSON() jQuery shorthand function.

If you don't use jQuery (or dojo which has an equivalent) you can use the powerful JavaScript JSON object.

var myJSONData = JSON.parse(data, reviver);

Where DATA is the the JSON data string and REVIVER is an optional function that will be called for every KEY and VALUE at every level of the final resulting object. Each value will be replaced by the result of the REVIVER function. For example this can be used to change strings in the JSON text into JS Date() objects.

3. The thorny and potentially very insecure loading and execution of Code Blocks, probably the most common use of eval() function in Javascript. Anywhere you allow code as text to be passed and run in the browser is prone to attack, it is much better where possible not to do this. When you absolutely have to do it then I would say using the Function constructor is less risky than a bold eval() call.

var myCode = "... your JS code ..."
var doSomething = new Function(myCode)
doSomething.call()


This will have the same effect as EVAL() but is less prone to being found as an avenue of attack for the forces of chaos on the internet. ** Note** you can also use the constructor format below to pass parms to the code block.

var doSomething = new Function("..var1name..","..var2name..", etc .. "..myCodeString..")

On a side note but related note, when you create a normal JS function construct, the definition does not have to appear at the start of the script (though it is usually best to do so for the sake of clarity). It can even be defined after the the code that calls it. In most cases, no matter where you choose to define your function, the JavaScript engine will create the function at the start of the current scope. BUT and it is an all caps BUT if you need to construct a code block conditioned on an IF, like this
if( someThingIsTrue )
 {
 function doSomeThingWonderful.call() { .... }
 }


Mozilla based browsers will allow it, but most others do not as they will always evaluate the function, even if the condition evaluates to false. So do not try to declare functions in the way noted above. Declaring functions inside these statements is possible in all current browsers using assigned anonymous functions, so it is better to do it this way.

var doSomeThingWonderful;
if( someThingIsTrure ) {
  doSomeThingWonderful = function () { --CodeBlock A--};
} else {
  doSomeThingWonderful = function () { --CodeBlock B--};
}
doSomeThingWonderful.call()

There are other reasons you need to evaluate objects or code  but generally there are ways around most of them that whilst potential slower to process are more secure and sensible.



     

Disqus for Domi-No-Yes-Maybe