Bugwards compatible

Bugwards compatible is a property of a system, product, process or technology that assures that older bugs are retained and not fixed since the quirk of the bug is used to gain features originally not intended.
Fixing such a bug would break the systems, products, processes or technologies depending on or using it. This would cause substantial cost for the consumers when compensating for the loss of features.

Advertisements

Why do we create conflicts?

Personally I feel that I’m involved in less micro conflicts than many of the people around me.
I think I have an answer to that.
My focus is on what people are saying and not how!
Personally I believe that if we all could stop focusing on how and try to understand what people are saying, we would have less conflicts.
To reduce the personal impact on how things are told I believe it’s necessary to understand how to communicate with less violence and above all become more prestigeless.

DLNA videos on ZTE MF93D

Bought a unlocked ZTE MF93D to take with me on our vacation. Selected this over the Huawei E5776 since it was available at a local store to very good price.

Have been reeding a lot compering the two and in the end my conclusion was that there are no big difference between them. ZTE you can use MiMo (dual external antenna) in low signal condition but the HUWEI has a bit better internal antenna and max throughput on 4G. But what difference does 150 Mbps for Huawei and 100Mbps for the ZTE really do when you do not intend to stream multiple movies over 4G.

Have been trying to get the dlna to work, but to get the movies to show up in the Video folder has not been easy. Google didn’t have the answer.

No manual saying what limitation there are and support could not help directly, they needed to escalate it.

So after some testing I found that the following works:

  • .mp4
  • .wmv

Did not work:

  • .m4v
  • .avi
  • .mkv
  • .mov
  • .divx
  • .xvid

So now I have to turn on the converter at home, so that my kids can stream movies on our iPads when we drive the 2000km down to Munich.

In Germany I buy prepaid surf card for the ZTE router and we can all surf without using expensive roaming. With some extra battery pack we can be on the move the whole day.

Vacation here we come!

Finding your XPage generated elements byId client side

Ok so when you create your fields or divs in XPage and you give them a sane Id, when XPage then renders them you get ids like:

id=”view:_id1:_id2:ContentControl:CompanyName”

I do see why it is necessary, since you can have multiple forms in one XPage and it would be impossible to keep them apart if fields did not have unique names.

But what if you have your JavaScript libraries which uses functions like getElementById or if you are smarter than that and uses the dojo.byId which is browser independent.

There is no way using the client side syntax (#{id:comboBox}) you can use in the XPage and custom controls.

At the moment I see two approaches, the first is to create a global variable which is then used in the JavaScript library. This method is described here!

http://www-10.lotus.com/ldd/ddwiki.nsf/dx/element_ids_in_client_side_javascript_on_xpages.htm

The second method is to use dojo.query().

dojo.query can be used to “query” the DOM tree, a really powerful function which is well worth digging into.

But in this case we will use it to find our html element by querying for the elements where id ends with the id we are looking for.

The syntax would be dojo.query(“[id$=’:CompanyName’]”).

Let’s take it apart. The brackets means we are searching for a tag with the name “id” ([id$=’…), which value ends with our search string, ‘$=’ stands for ends with.

The search string begins with a colon since we want to be sure we do not get fields with ids like ‘FirstCompanyName’, since they also ends with ‘CompanyName’.

The result will be an array of html elements, with multiple entries if more than one element id ends with ‘:CompanyName’, which very well may be the case, see when to use section below.

So when do we use which one:

The first method is preferred if you have multiple forms as data sources for your fields or when you cannot be absolutely sure that the ids are unique over all elements you need to use in your JavaScript library!

In all other cases the second method should work fine.

So now you have to rewrite all your JavaScript libraries! Yes you do and when you do that try to skip everything which takes an id string as a parameter, rewrite it to use elements or better to take both types as an argument.

Function doSomthingWithElement(elmnt){
 if(typeof(elmnt) === ‘string’){
   elmnt = dojo.byId(elmnt);
 }
 // use the element
 alert(elmnt.innerHTML);
}

What you also can do is to replace the XSP objects method getElementById with your own implantation of it using the dojo.query().

Either put the code inside addOnLoad in the client side XPage event onClientLoad or better put the code below in to a JavaScript library which is added as a resource into the XPage. Be sure to put in the JavaScript library early in the code so that it is loaded before used.

The XSP object is created by Domino server and contains different convenient functions like a getElementsById which actually only is a wrapper around dojo.byId()!

dojo.addOnLoad(function(){
 dojo.mixin(XSP, {
   getElementById: function(idName){
     var result = dojo.byId(idName);
     if (!result){
       result = dojo.query("[id$=':" + idName + "']");
       if (result){
         result = result[0];
       }
     }
     return result;
   }
 })
});

I’ll try to explain what happens: First the dojo.addOnLoad() will run the function given as a parameter when the page has loaded in the client. Then by using dojos mixin the script replaces the object literal entry for “getElementById” with the code given as a second parameter. The code itself doing the magic first tries to find the element the classic way by using dojo.byId(). In this way we do not break the previous functionality. If nothing is found it tries to find the element by using the dojo.query() method described above.

So now if you want to find an element where the id has been replaced by the Domino XPage rendering engine you can use XSP.getElementById(‘CompanyName’) as you hopefully are used to.

An alternativ can be to mixin xspById() into dojo.

If someone knows of a function which can be used instead in custom JavaScript libraries please tell me since I’ve been searching a lot for a solution to this problem.

1Kg iron vs. 1Kg feathers

Is configuring an of-the-shelf software less expensive than developing it on an existing application platform? Configuring always sounds more economical. That is as delusive as to say that 1 Kg iron has more mass than 1 Kg feathers.

But it’s hard to compare configuration complexity and code reusability!

Feathers always sounds so light!

The XPage vs. JavaScript library and getElementById issues

Ok so when you create your fields or divs in XPage and you give them a sane Id, when XPage then renders them you get ids like:

id=”view:_id1:_id2:ContentControl:CompanyName”

Please do notice that this applies only to script code which is loaded into the XPage. I’m well aware of that JavaScript entered directly into the Xpage or custom control will not have the problem, since there are many diffrent way to reference the rebuilt XPage-id.

I do see why it is necessary, since you may have multiple forms in one XPage and it would be impossible to keep them apart if fields did not have unique names.

But what if you have your old JavaScript libraries which uses functions like getElementById or if you are smarter than that and uses the dojo.byId() which is browser independent.

There is no way using the client side syntax like #{id:comboBox} in JavaScript libraries. Works fine in XPages and custom controls though.

At the moment I see two approaches, the first is to create a global variable which is then used in the JavaScript library. This method is described here!

The second method is to use dojo.query()!

dojo.query can be used to “query” the DOM tree, a really powerful function which is well worth digging into.

But in this case we will use it to find our html element by querying for the elements where XPage-id ends with the id we are looking for.

So the syntax is dojo.query(“[id$=’:CompanyName’]”).

Let’s take it apart. The brackets means we are searching for a tag with the name “id” ([id$=’…), which value ends with our search string, ‘$=’ stands for ends with.

The search string begins with a colon since we want to be sure we do not get fields with ids like ‘FirstCompanyName’, since they also ends with ‘CompanyName’.

The result will be an array of html elements, with multiple entries, which may be the case!
I’ll try to explain why and when to use which?

The first method is preferred if you have multiple forms as data sources for your fields in the XPage or when you cannot be absolutely sure that the ids are unique over all elements used in your JavaScript library!
In all other cases the second method should work fine!

So now you have to rewrite all your JavaScript libraries! Yes you do! And when you do that try to skip everything which takes an id string as a parameter, rewrite it to use elements or better accepts both types as an argument.

Function doSomthingWithElement(elmnt){
  if(typeof(elmnt) === ‘string’){
    elmnt = dojo.byId(elmnt);
  }
  // use the element
  alert(elmnt.innerHTML);
}

Now with a little twist of customization!

What you also can do is to replace the XSP objects method getElementById with your own implantation of it, using the dojo.query().

Either put the code you find as parameter to dojo.addOnLoad in the client side XPage event onClientLoad or better put the code below in to a JavaScript library where you have your common functions, then add it as a resource into the XPage.

The XSP object is created by Domino server and contains different convenient functions like getElementsById which actually is a wrapper for dojo.byId()!

dojo.addOnLoad(function(){
  dojo.mixin(XSP, {
    getElementById: function(idName){
      var result = dojo.byId(idName);
      if (!result){
        result = dojo.query("[id$=':" + idName + "']");
        if (result){
          result = result[0];
        }
      }
      return result;
    }
  })
});

I’ll try to explain what happens.

First the dojo.addOnLoad() will run the function given as a parameter when the page has loaded in the client. Then by using dojos mixin the script replaces the object literal entry for “getElementById” with the code given as a second parameter. The code itself doing the magic first tries to find the element the classic way by using dojo.byId(). In this way we do not break the functionality. If no elements are found it tries to find the element by using the dojo.query() as described above.

So now if you want to find an element where the id has been replaced by the Domino XPage rendering engine you can use XSP.getElementById(‘CompanyName’).

It’s also possible to add it to the dojo object by altering the code to:

dojo.mixin(dojo, {
    xspById: function(idName){

I’ve did not manage to replace the dojo.byId() since it references it self in a “strange” way which is broken when you use dojo.mixin

If  someone knows of a function which can be used instead in custom JavaScript libraries please comment!

@URLEncode and the JavaScript equivalent!

JavaScript has many different encoding function with different approaches. Some of them does not encode all special characters.
escape() – does not encode: *@-_+./
encodeURI() – Does not encode: ,/?:@&=+$#

But encodeURIComponent() encodes all special characters! Link to W3SChool

@URLEncode(“ISO-8859-1;”,/?:@&=+$#”) will encode to the following string: “%2C%2F%3F%3A%40%26%3D%2B%24%23%22”
Which means that @URLEncode is similar to encodeURIComponent()!

But be warned @URLEncode/@URLDecode in standard uses “Domino” as decode type. “Domino” uses UTF-8 char set which will not work together with standard encoding on a  web page togehter with the JavaScript encode and decode functions . To work well with international characters use “ISO-8859-1”.

When it comes to encoding keep in mind that the decodeURI() function will skip decoding escaped characters which encodeURI() will not encode (at least in Firefox). @URLDecode and the JavaScript functions unescape() and decodeURIComponent() will decode all % escaped characters.

So decoding the string above will give the following result:

unescape() => ,/?:@&=+$#”
decodeURI() => %2C%2F%3F%3A%40%26%3D%2B%24%23″
decodeURIComponent() => ,/?:@&=+$#”

Conclusion:
@URLDecode will decode anything encoded with any of the JavaScript alternatives correctly.
@URLEncode will only be correctly encoded by the JavaScript functions unescape() and decodeURIComponent().