Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 1 of 3 123 LastLast
Results 1 to 15 of 34

Thread: String replace

  1. #1
    New Coder
    Join Date
    Dec 2012
    Posts
    18
    Thanks
    13
    Thanked 0 Times in 0 Posts

    String replace

    Hi,

    I'm using a XML which one of the paramets output is this:

    Complete assigned tasks </div><br/></div><br/><br/><div>
    What I wanna do is to find all "<" and ">" and replace them.

    I have this code for this:

    <script type="text/javascript">
    var myOldString = "<p>Complete assigned tasks as directed by Management.&lt;/div&gt;&lt;br/&gt;&lt;/div&gt;&lt;br/&gt;&lt;br/&gt;&lt;div&gt;";
    var myNewString = myOldString.replace(/&lt;/g, "a");(/&gt;/g, "b");

    document.write( myNewString);
    </script>
    Was also thinkin maybe I can use this replacement on every component on my page and not only on specific var?


    Thanks.

  • #2
    Regular Coder
    Join Date
    Mar 2008
    Location
    London
    Posts
    152
    Thanks
    4
    Thanked 42 Times in 42 Posts
    a bit correction in your code -
    Code:
    myNewString = myOldString.replace(/&lt;/g,'<').replace(/&gt;/g,'>');

  • #3
    New Coder
    Join Date
    Dec 2012
    Posts
    18
    Thanks
    13
    Thanked 0 Times in 0 Posts
    Hey , thanks working!!

    Now another question
    is there any problem with this code:
    Code:
    if (PageNumber = 1)
    {
    	Tiggzi('prevButton').hide();
    }
    else
      {
      if ( PageNumber > 1)
      {
    	  Tiggzi('prevButton').show();
      }
     }
    For some reason it isn't working for me.

  • #4
    Supreme Master coder! Philip M's Avatar
    Join Date
    Jun 2002
    Location
    London, England
    Posts
    18,082
    Thanks
    203
    Thanked 2,542 Times in 2,520 Posts
    if (PageNumber = 1)

    Should be == for comparison.

    All the code given in this post has been tested and is intended to address the question asked.
    Unless stated otherwise it is not just a demonstration.

  • Users who have thanked Philip M for this post:

    bm1125 (02-08-2013)

  • #5
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    26,232
    Thanks
    80
    Thanked 4,456 Times in 4,421 Posts
    If Philip's answer doesn't fix it:

    How can we possibly guess, since you don't show us the code you are using for show() or hide()?

    No, show() and hide() are *NOT* inherent methods on objects. jQuery supports them, but only if you access the object via a jQuery selector, either directly or indirectly.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  • Users who have thanked Old Pedant for this post:

    bm1125 (02-08-2013)

  • #6
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    Quote Originally Posted by Philip M View Post
    Should be == for comparison.
    It is preferable to avoid using == in JavaScript where possible. === is the better comparison operator to use and should work fine in this instance.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • Users who have thanked felgall for this post:

    bm1125 (02-08-2013)

  • #7
    Supreme Master coder! Philip M's Avatar
    Join Date
    Jun 2002
    Location
    London, England
    Posts
    18,082
    Thanks
    203
    Thanked 2,542 Times in 2,520 Posts
    Quote Originally Posted by felgall View Post
    It is preferable to avoid using == in JavaScript where possible. === is the better comparison operator to use and should work fine in this instance.
    I don't really see why you say that. The Mozilla Development Network says

    Use strict equality operators if the operands must be of a specific Type as well as value or if the exact Type of the operands is important. Otherwise, use the standard equality operators, which allow you to compare the identity of two operands even if they are not of the same Type.

    I agree with that. Automatic type conversion is one of the advantages of Javascript which ought not to be rejected. Use of strict equality comparisons is often completely unnecessary. Even if you don’t use == in your code someone else will (e.g. jQuery).

    The === operator would seem to have little point when comparing strings:-

    Code:
    <script type = "text/javascript">
    
    var a = "felgall";
    var b = "felgall";
    alert (a==b); // true
    alert (a===b);  // true
    
    </script>
    In any case there is no >== or <==, only <= and >= so comparisons of this pattern (which are probably as common as ==) use type conversion.

    Code:
    <script type = "text/javascript">
    
    var a = 3;
    var b = "5";
    alert (b>=a);  // true
    
    </script>
    Last edited by Philip M; 02-08-2013 at 08:51 AM.

    All the code given in this post has been tested and is intended to address the question asked.
    Unless stated otherwise it is not just a demonstration.

  • #8
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,380
    Thanks
    11
    Thanked 592 Times in 572 Posts
    i agree with 80% of crockford's dogma, but "==" has its place. it's probably better to encourage == so that form values can compare to numbers without the explicit type conversion boilerplate of languages from the 60s...
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.6, IE11:9.1, IE9:3.1, IE10:3.0, FF:17.2, CH:46, SF:11.4, NON-MOUSE:38%

  • #9
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    Quote Originally Posted by Philip M View Post
    Automatic type conversion is one of the advantages of Javascript which ought not to be rejected.
    It is actually one of the biggest disadvantages that JavaScript has. A significant fraction of errors made by those who are relatively new to JavaScript are caused by the fact that JavaScript is not a strongly typed language. At least that's been my experience wit the sorts of errors I have seen in beginner's code.

    I do agree that == has its place but only where you don't know the type of one of the two values being compared and are doing the comparison to work out whether it can be meaningfully converted to a specific type. Where the types of both values is known then specifically converting them to the same type in order to compare them reduces the chances of errors later.

    To use your example to illustrate this - given that a and b are variables for a subsequent call to the same comparison they could have different values assigned and then the == might give the wrong result:

    Code:
    <script type = "text/javascript">
    
    var a = "10";
    var b = 10;
    alert (a==b); // true
    alert (a===b);  // false
    alert(''+a===''+b) // true when both are converted to strings
    
    </script>
    also consider this one:

    Code:
    <script type = "text/javascript">
    
    var a = new Date(2013,1,9);
    var b = new Date(2013,1,9);
    alert (a==b); // false because the objects are not the same
    alert (a===b);  // false
    alert(''+a===''+b) // true
    
    </script>
    Add those two to your original example and you can easily see how == does not always produce the expected result whereas using === and converting to a specific type does give the right result in those instances where == gets it wrong.

    Allowing the == to do the conversion can also be confusing - '9'==9 converts the number to a string in JavaScript but in PHP the same comparison converts the string to a number. For someone used to one language learning the other this can lead to subtle differences from the expected result.
    Last edited by felgall; 02-08-2013 at 07:59 PM.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #10
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,380
    Thanks
    11
    Thanked 592 Times in 572 Posts
    Quote Originally Posted by felgall View Post
    Allowing the == to do the conversion can also be confusing - '9'==9 converts the number to a string in JavaScript but in PHP the same comparison converts the string to a number. For someone used to one language learning the other this can lead to subtle differences from the expected result.
    what difference does it make how the conditional is internally decoded?

    The conditional's true/false result is the same either way under any scenario my feeble mind can imagine.


    if you wanted the string to become a number, simply add "+" to the equation: (+'9'==9). this forces a numerical conversion upon the string just before the comparison is assessed.


    i think one of the reasons people make mistakes like that in JS is because they used old-fashioned static typed languages first. boo on them. For people who start in JS, i don't see those mistakes happening very often. 1989 was a long time ago, let's all get our mental models caught up to dynamic data representation.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.6, IE11:9.1, IE9:3.1, IE10:3.0, FF:17.2, CH:46, SF:11.4, NON-MOUSE:38%

  • #11
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    26,232
    Thanks
    80
    Thanked 4,456 Times in 4,421 Posts
    Here's a fun one to throw into the mix:
    Code:
    var a = parseFloat("77");
    var b = parseInt("77");
    if ( a===b ) { alert("Scares people used to strongly typed languages"); }
    I do have to agree with Philip: If we can have === and !==, then where in the heck are >== and <== ???

    Heh. And how can JS assure a type-checked < or > in any case?

    You almost wish that "strict" mode would also insist that comparisons don't work at all on values of different types. Or maybe I more than "almost" wish that, come to think of it.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  • #12
    Supreme Master coder! Philip M's Avatar
    Join Date
    Jun 2002
    Location
    London, England
    Posts
    18,082
    Thanks
    203
    Thanked 2,542 Times in 2,520 Posts
    Quote Originally Posted by Old Pedant View Post
    Here's a fun one to throw into the mix:
    Code:
    var a = parseFloat("77");
    var b = parseInt("77");
    if ( a===b ) { alert("Scares people used to strongly typed languages"); }
    I have to say it does not scare me in the slightest, as it is obvious to me that both are numbers.

    I don't see the point of felgall's date comparison example. You cannot compare two date objects. Two objects are strictly equal if (and only if) they refer to the same object. And alert(''+a==''+b) is just as true as alert(''+a===''+b).


    rnd me regards static type languages as old-fashioned. I don't have the expertise to comment, but I still think that automatic type conversion is one of the advantages of Javascript which ought not to be rejected.

    As usual, let us agree to disagree. To some extent it is a matter of "house style".
    Last edited by Philip M; 02-09-2013 at 08:35 AM.

    All the code given in this post has been tested and is intended to address the question asked.
    Unless stated otherwise it is not just a demonstration.

  • #13
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,380
    Thanks
    11
    Thanked 592 Times in 572 Posts
    Quote Originally Posted by Philip M View Post
    rnd me regards static type languages as old-fashioned.
    it's an indisputable fact of history that strong typing came first. Machine languages need to be strong typed, for good reason. At some level, all languages are executed with strong types, even javascript.

    The difference is that the machine does the tedious work of type conversion in JS. Compared to older languages like C, C++, or even Java, JS does a lots of tedious work for you: memory management, auto local name closures, semi-colon insertion, automatic function hoisting, etc. If you are awesome, not over-worked and smart, you can probably do a better job yourself. This is not unlike the age-old debate of using jQurey -vs- hand-built code.

    as with anything mechanical, trade offs result. A honda civic with a good driver and a stick shift can always undercut the quarter-mile time of the same driver driving a civic with an automatic transmission.

    So which car is better?

    In this context, i think it's an obvious opinion, and only a fool would claim otherwise.

    you might have caught a typo or two earlier with strict types, but with modern IDEs like M$ VS2012 (and many more soon, just wait), you can see those errors as you type, before you even save, much less compile.
    plus we have jslint and jshint, in some editors in real-time, to enforce the level of convention and control a project is slated for, including using "==" where "===" would work.

    in those respects, weak typing is a new-fashion way of coding with some but increasingly fewer disadvantages to it's predecessors.
    Last edited by rnd me; 02-10-2013 at 07:35 AM.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.6, IE11:9.1, IE9:3.1, IE10:3.0, FF:17.2, CH:46, SF:11.4, NON-MOUSE:38%

  • #14
    Regular Coder
    Join Date
    Jan 2013
    Location
    Germany
    Posts
    578
    Thanks
    4
    Thanked 77 Times in 77 Posts
    Coming from a background of mostly web development, I was a fan of weak-typed languages for a long time. Eversince I started getting more and more into, for example, Java, I like strong-typed languages better. It just feels cleaner to work with correct types and not compare apples and oran… I mean numbers and strings. And even weak-typed languages usually allow you to work with types – they also just allow you to be lazy. And these days I just try to get rid of laziness in programming as much as possible.

    @ Old Pedant (yes, some people can get your name right )

    The "problem" I have with that example is that integers and floating points are different objects in languages like the C family etc., but they are not in JavaScript – they both are of the type "Number" and therefore equal.
    However, the same argument can't be used for strings and numbers. "5" == 5 might still be true, but "5" and 5 are not of the same type (String <-> Number). JavaScript just allows the type-insensitive comparison, but they are not the same objects.

    All in all: I personally prefer using === whenever I can. I also check types. Currently I'm working with qooxdoo, which even automatically checks for types and makes JavaScript much stricter – and I like it.

    BUT:

    But let's forget about personal preferences. What about == versus === in pure terms of performance? Well, I prepared a little test: http://jsperf.com/the-truth-about-comparisons
    It tests all combinations of types and result for both == and ===. What's the result?

    Well: As long as types are equal, == and === don't make much of a difference. Actually, === may even be slightly slower. But that's the point: slightly slower and only maybe. Doesn't really surprise, does it?
    But this wasn't the point, because people argue in favor of == when types are different. For different types, the result couldn't be much clearer: === outperforms == by a lot. And that's simply because once the types are checked to be different, actually checking the value becomes unnecessary.

    So whenever you need to care about performance (i.e. loops), === should be the way to go. As for ==, there is no real argument in favor of it except that you can be lazy not to care about the types, which will save you some code.

    To summarize it with a personal note again: Laziness should never ever be a justification for your code. Also, performance is always an issue on the web, especially if mobile development is involved.

  • #15
    Regular Coder
    Join Date
    Jan 2013
    Location
    Germany
    Posts
    578
    Thanks
    4
    Thanked 77 Times in 77 Posts
    Just to point one thing out even more:

    If you look at the results, === performs about ten times faster than == when types are different.

    That's not as much as, for example, the complexity of different sorting algorithms where you go from O(n²) to O(n * log n), but a factor of ten is a huge improvement. And it's as cheap as one additional "=".


    Maybe the main argument against my test is now going to be that "5"==5 is true and "5"===5 isn't, so they produce different results which may not be wanted. And that means you'd need to convert before using ===. Which will slow it down again.

    However, the following test shows that even if you only compare once, conversion + === is still faster than ==. Using more than one comparison, the initial conversion will outperform == even more: http://jsperf.com/versus-conversion


  •  
    Page 1 of 3 123 LastLast

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •