{"id":942,"date":"2012-10-27T13:29:29","date_gmt":"2012-10-27T13:29:29","guid":{"rendered":"http:\/\/www.sitekickr.com\/blog\/?p=942"},"modified":"2012-11-07T22:48:44","modified_gmt":"2012-11-07T22:48:44","slug":"javascript-strings-prototype","status":"publish","type":"post","link":"https:\/\/www.sitekickr.com\/blog\/javascript-strings-prototype\/","title":{"rendered":"Fun with JavaScript Strings and Prototype"},"content":{"rendered":"

My recent post titled Fun with JavaScript Numbers and Prototype<\/a> got a lot more attention than I thought it would. So, I considered it cruel not to give String objects equal treatment.<\/p>\n

More than a few reader's of my previous post on numbers pointed out that some of the functions I created were little more than semantically different from built-in functions. I agree, and that's okay. For me, adding functions to a built-in object's prototype doesn't serve to create cutting-edge string manipulation routines, but rather to reduce the complexity of my code, by encapsulating commonly used algorithms into an easy-to-call function.<\/p>\n

Using a built-in object's prototype not only allows us to use a more intuitive syntax:<\/p>\n

newString = myString.awesomeFunction();
\n\t<\/code><\/p>\n

But also helps us to maintain functional cohesion<\/a> within our objects. Meaning, we don't need to scramble a bunch of unrelated functions together into a giant utility class, i.e.<\/p>\n

newString = util.awesomeFunction(myString);
\n\t<\/code><\/p>\n

Not only does this lengthen our code, but it's disorganized. A function that does string manipulation has no business in a class (object) that calculates the perimeter of a rectangle.<\/p>\n

Furthermore, it wouldn't make sense to create another class (object) to house string manipulation methods when we already have the perfect one built in – the String object.<\/p>\n

So, let's have some fun with String's prototype!<\/p>\n

 <\/p>\n

Occurrences in a string<\/h3>\n

Sure, this one's easy. Just perform a RegEx match. But, to someone else reading your code, it might not be immediately apparent what you're trying to do.<\/p>\n

myString = 'this is my string';\r\nnumTimes = myString.match(\/is\/g).length;<\/code><\/pre>\n
Drop that into a function on String's prototype and you've got more readable code at the very least:<\/p>\n
String.prototype.occurrences = function(substring) {
\n\t  var occRegEx = new RegExp(substring, 'g');
\n\t  return this.match(occRegEx).length;
\n\t}<\/p>\n
\t> myString.occurrences('is');
\n\t  2<\/span>
\n\t<\/code><\/p>\n
Okay, that was not awesome. Hey, I'm just getting started!<\/p>\n
 <\/p>\n
Logging<\/h3>\n
What's the scariest thing about JavaScript? It runs in the user's browser, you have no eyes and ears! One of my favorite post-launch debugging strategies on the server side is having an email sent to me any time there's an error on the site. Easily accomplished with server-side code, right. Not so easy on the client side. But, not impossible. I'm admittedly going to break the rule of cohesion here. A logging function really doesn't belong in company of string manipulation functions. <\/strong>This concept is just too cool to pass up though.<\/p>\n
Wouldn't it be great to just drop in a statement like:<\/p>\n
myString.serverLog();
\n\t<\/code><\/p>\n
and have it append to a server-side error log, along with a few context identifiers? Let's make it happen:<\/p>\n
String.prototype.serverLog = function() {
\n\t  \/* you can find implementations of an xmlHttpPost AJAX call anywhere and everywhere on the web
\n\t     I won't waste your time recreating it here. *\/
\n\t  var logString = this + ' | ' + (new Date()).toString() + ' | ' + location.href;
\n\t  xmlHttpPost('\/log.php?s=' + logString);
\n\t}
\n\t<\/code><\/p>\n
Put that in the context of a try\/catch block and it becomes a lot more useful:<\/p>\n
    try {\r\n     x = y;\r\n    }\r\n    catch(e) {\r\n     if(typeof arguments !== 'undefined') {\r\n       console.log(arguments.callee.toString().match(\/function\\s+([^\\s\\(]+)\/)[0])\r\n     }\r\n     console.log(e.toString());\r\n    }\r\n<\/pre>\n
try {
\n\t  x = something;
\n\t}
\n\tcatch(e) {
\n\t  var soThisHappened = '';
\n\t  soThisHappened += e.toString();
\n\t  if(typeof arguments !== 'undefined') {
\n\t    \/\/ if we're inside a function, snag the function name
\n\t    soThisHappened += arguments.callee.toString().match(\/function\\s+([^\\s\\(]+)\/)[0]);
\n\t  }
\n\t  soThisHappened.serverLog();
\n\t}<\/p>\n
\t<\/code><\/p>\n
Markup<\/h3>\n
How many times have you written or seen JavaScript like this, myself included:<\/p>\n
if(document.form1.name.value === '') {
\n\t  document.write('<b>Oh no, you forgot your name?<\/b>');
\n\t}<\/code><\/p>\n
\tAll those gurus are always telling you to keep JavaScript out of your HTML, so shouldn't the reverse apply? But, I really want to just spit out a boldface message. Here's a cleaner way:<\/p>\n
String.prototype.bold = function() {
\n\t  return '<b>' + this + '<\/b>';
\n\t}<\/p>\n
\tdocument.write('Oh no, you forgot your name?'.bold());
\n\t<\/code><\/p>\n
 <\/p>\n
Language<\/h3>\n
The previous couple functions walk the line of cohesion and usefulness, maybe even step over it. So, let's get back to the core of what a string is: typically a word or group of words in a given language. The String prototype is the perfect home for language functions.<\/p>\n
String.prototype.isQuestion = function() {
\n\t   var questionIdentifiers = ['when', 'where', 'why', 'what', 'who', 'how', 'can'];<\/p>\n
\t   \/\/ does the string contain a question mark?
\n\t   if(this.indexOf('?') !== -1) {
\n\t      return true;
\n\t   }
\n\t   
\n\t   \/\/ search keyword may indicate a question without explicitly specifying the question mark
\n\t   for(var i = 0; i < questionIdentifiers.length; i++) {
\n\t      if(this.indexOf(questionIdentifiers[i]) !== -1) {
\n\t         return true;
\n\t      }
\n\t   }<\/p>\n
\t   return false;
\n\t}<\/code><\/p>\n
We could use our new function to refine a user's search by conditionally returning results more likely to answer questions, than to provide generic information:<\/p>\n
if(searchPhrase.isQuestion()){
\n\t  \/\/ favor search results in the knowledge base
\n\t}
\n\telse {
\n\t  \/\/ favor search results in the product store
\n\t}<\/code><\/p>\n
 <\/p>\n
Is it a Word?<\/h3>\n
There's an unfair bias towards the numeric <\/em>in computer science. Of course, it all stems from the fact that the CPU speaks numeric<\/em>, while we humans speak string<\/em>. You can follow a gradual trend towards natural language-based syntax in popular development languages such as ColdFusion and Python. But, there really isn't much happening in terms of native support for natural language processing. I'm a little surprised by this, because I feel as if half of the applications that I develop require at least a very primitive form of natural language processing (search, form validation, speech recognition, etc.)<\/p>\n
Many languages offer isNumeric()<\/tt>, isDate()<\/tt>, or isArray() <\/tt>functions. But, how about isWord()<\/tt>, isVerb()<\/tt>, isCommand()<\/tt>?<\/p>\n
isCommand()<\/tt> could be used in searching algorithms (similar to isQuestion()<\/tt>) above. If a command is detected, the user might know more or less what they are looking for, otherwise, they may need a deeper level of assistance.<\/p>\n
isWord()<\/tt> could be used in form validation. If a user submits a field, validate that it's actually a word (or group of words). The definition of a word is subjective, but we'll make a few assumptions:<\/p>\n
    \n
  1. A word does not contain spaces<\/li>\n
  2. A word can contain only letters or the hyphen<\/li>\n
  3. A word is less than 25 characters in length<\/li>\n<\/ol>\n
    String.prototype.isWord = function() {
    \n\t  if(this.length > 25) {
    \n\t    return false;
    \n\t  }
    \n\t  return \/^[A-Za-z\\-]*$\/.test(this);
    \n\t}<\/code><\/p>\n
    A user submits a form which has fields for first and last name, so you validate against our new isWord() function:<\/p>\n
    if(!firstname.isWord()) {
    \n\t  alert('Is that really your name?');
    \n\t}<\/code><\/p>\n
    Well, maybe it isn't. Many folks out there have a two-word first name. So, let's expand our String prototype to help out here:<\/p>\n
    String.prototype.words = function() {
    \n\t  return this.split(' ');
    \n\t}<\/code><\/p>\n
    Now we are armed with the basics necessary to properly validate a first name:<\/p>\n
    for each(item in firstname.words()) {
    \n\t  if(!item.isWord()) {
    \n\t    alert('Is that really your first name?');
    \n\t    break;
    \n\t  }
    \n\t}
    \n\t<\/code><\/p>\n
     <\/p>\n
    <\/p>\n
    Functions floating around the web<\/h3>\n
    This part is more for reference. The following functions are so common, that I thought my post would be incomplete without offering them. They are not my own.<\/p>\n
    String.prototype.capitalize = function() {
    \n\t    return this.replace(\/(&)?([a-z])([a-z]{2,})(;)?\/ig, function (all, prefix, letter, word, suffix) {
    \n\t        if (prefix && suffix) {
    \n\t            return all;
    \n\t        }
    \n\t        return letter.toUpperCase() + word.toLowerCase();
    \n\t    }); 
    \n\t<\/span>}<\/code><\/p>\n
    String.prototype.ltrim = function() { 
    \n\t    \/\/ remove "padding" before the string
    \n\t    return this.replace(\/^\\s+\/, ''); 
    \n\t};
    \n\t<\/code><\/p>\n
    String.prototype.rtrim = function() {
    \n\t    \/\/ remove "padding" after the string
    \n\t    return this.replace(\/\\s+$\/,'');
    \n\t};
    \n\t<\/code><\/p>\n
    String.prototype.repeat = function( num )
    \n\t{
    \n\t    \/\/ repeat a string num<\/em> times
    \n\t    return new Array( num + 1 ).join( this );
    \n\t}
    \n\t<\/code><\/p>\n","protected":false},"excerpt":{"rendered":"
    My recent post titled Fun with JavaScript Numbers and Prototype got a lot more attention than I thought it would. So, I considered it cruel…<\/p>\n","protected":false},"author":1,"featured_media":1010,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"amp_status":""},"categories":[5],"tags":[218,199,227],"_links":{"self":[{"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/posts\/942"}],"collection":[{"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/comments?post=942"}],"version-history":[{"count":20,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/posts\/942\/revisions"}],"predecessor-version":[{"id":1087,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/posts\/942\/revisions\/1087"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/media\/1010"}],"wp:attachment":[{"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/media?parent=942"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/categories?post=942"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/tags?post=942"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}