Search Results

Search found 34772 results on 1391 pages for 'javascript objects'.

Page 1/1391 | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

  • Integrating JavaScript Unit Tests with Visual Studio

    - by Stephen Walther
    Modern ASP.NET web applications take full advantage of client-side JavaScript to provide better interactivity and responsiveness. If you are building an ASP.NET application in the right way, you quickly end up with lots and lots of JavaScript code. When writing server code, you should be writing unit tests. One big advantage of unit tests is that they provide you with a safety net that enable you to safely modify your existing code – for example, fix bugs, add new features, and make performance enhancements -- without breaking your existing code. Every time you modify your code, you can execute your unit tests to verify that you have not broken anything. For the same reason that you should write unit tests for your server code, you should write unit tests for your client code. JavaScript is just as susceptible to bugs as C#. There is no shortage of unit testing frameworks for JavaScript. Each of the major JavaScript libraries has its own unit testing framework. For example, jQuery has QUnit, Prototype has UnitTestJS, YUI has YUI Test, and Dojo has Dojo Objective Harness (DOH). The challenge is integrating a JavaScript unit testing framework with Visual Studio. Visual Studio and Visual Studio ALM provide fantastic support for server-side unit tests. You can easily view the results of running your unit tests in the Visual Studio Test Results window. You can set up a check-in policy which requires that all unit tests pass before your source code can be committed to the source code repository. In addition, you can set up Team Build to execute your unit tests automatically. Unfortunately, Visual Studio does not provide “out-of-the-box” support for JavaScript unit tests. MS Test, the unit testing framework included in Visual Studio, does not support JavaScript unit tests. As soon as you leave the server world, you are left on your own. The goal of this blog entry is to describe one approach to integrating JavaScript unit tests with MS Test so that you can execute your JavaScript unit tests side-by-side with your C# unit tests. The goal is to enable you to execute JavaScript unit tests in exactly the same way as server-side unit tests. You can download the source code described by this project by scrolling to the end of this blog entry. Rejected Approach: Browser Launchers One popular approach to executing JavaScript unit tests is to use a browser as a test-driver. When you use a browser as a test-driver, you open up a browser window to execute and view the results of executing your JavaScript unit tests. For example, QUnit – the unit testing framework for jQuery – takes this approach. The following HTML page illustrates how you can use QUnit to create a unit test for a function named addNumbers(). <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <title>Using QUnit</title> <link rel="stylesheet" href="http://github.com/jquery/qunit/raw/master/qunit/qunit.css" type="text/css" /> </head> <body> <h1 id="qunit-header">QUnit example</h1> <h2 id="qunit-banner"></h2> <div id="qunit-testrunner-toolbar"></div> <h2 id="qunit-userAgent"></h2> <ol id="qunit-tests"></ol> <div id="qunit-fixture">test markup, will be hidden</div> <script type="text/javascript" src="http://code.jquery.com/jquery-latest.js"></script> <script type="text/javascript" src="http://github.com/jquery/qunit/raw/master/qunit/qunit.js"></script> <script type="text/javascript"> // The function to test function addNumbers(a, b) { return a+b; } // The unit test test("Test of addNumbers", function () { equals(4, addNumbers(1,3), "1+3 should be 4"); }); </script> </body> </html> This test verifies that calling addNumbers(1,3) returns the expected value 4. When you open this page in a browser, you can see that this test does, in fact, pass. The idea is that you can quickly refresh this QUnit HTML JavaScript test driver page in your browser whenever you modify your JavaScript code. In other words, you can keep a browser window open and keep refreshing it over and over while you are developing your application. That way, you can know very quickly whenever you have broken your JavaScript code. While easy to setup, there are several big disadvantages to this approach to executing JavaScript unit tests: You must view your JavaScript unit test results in a different location than your server unit test results. The JavaScript unit test results appear in the browser and the server unit test results appear in the Visual Studio Test Results window. Because all of your unit test results don’t appear in a single location, you are more likely to introduce bugs into your code without noticing it. Because your unit tests are not integrated with Visual Studio – in particular, MS Test -- you cannot easily include your JavaScript unit tests when setting up check-in policies or when performing automated builds with Team Build. A more sophisticated approach to using a browser as a test-driver is to automate the web browser. Instead of launching the browser and loading the test code yourself, you use a framework to automate this process. There are several different testing frameworks that support this approach: · Selenium – Selenium is a very powerful framework for automating browser tests. You can create your tests by recording a Firefox session or by writing the test driver code in server code such as C#. You can learn more about Selenium at http://seleniumhq.org/. LTAF – The ASP.NET team uses the Lightweight Test Automation Framework to test JavaScript code in the ASP.NET framework. You can learn more about LTAF by visiting the project home at CodePlex: http://aspnet.codeplex.com/releases/view/35501 jsTestDriver – This framework uses Java to automate the browser. jsTestDriver creates a server which can be used to automate multiple browsers simultaneously. This project is located at http://code.google.com/p/js-test-driver/ TestSwam – This framework, created by John Resig, uses PHP to automate the browser. Like jsTestDriver, the framework creates a test server. You can open multiple browsers that are automated by the test server. Learn more about TestSwarm by visiting the following address: https://github.com/jeresig/testswarm/wiki Yeti – This is the framework introduced by Yahoo for automating browser tests. Yeti uses server-side JavaScript and depends on Node.js. Learn more about Yeti at http://www.yuiblog.com/blog/2010/08/25/introducing-yeti-the-yui-easy-testing-interface/ All of these frameworks are great for integration tests – however, they are not the best frameworks to use for unit tests. In one way or another, all of these frameworks depend on executing tests within the context of a “living and breathing” browser. If you create an ASP.NET Unit Test then Visual Studio will launch a web server before executing the unit test. Why is launching a web server so bad? It is not the worst thing in the world. However, it does introduce dependencies that prevent your code from being tested in isolation. One of the defining features of a unit test -- versus an integration test – is that a unit test tests code in isolation. Another problem with launching a web server when performing unit tests is that launching a web server can be slow. If you cannot execute your unit tests quickly, you are less likely to execute your unit tests each and every time you make a code change. You are much more likely to fall into the pit of failure. Launching a browser when performing a JavaScript unit test has all of the same disadvantages as launching a web server when performing an ASP.NET unit test. Instead of testing a unit of JavaScript code in isolation, you are testing JavaScript code within the context of a particular browser. Using the frameworks listed above for integration tests makes perfect sense. However, I want to consider a different approach for creating unit tests for JavaScript code. Using Server-Side JavaScript for JavaScript Unit Tests A completely different approach to executing JavaScript unit tests is to perform the tests outside of any browser. If you really want to test JavaScript then you should test JavaScript and leave the browser out of the testing process. There are several ways that you can execute JavaScript on the server outside the context of any browser: Rhino – Rhino is an implementation of JavaScript written in Java. The Rhino project is maintained by the Mozilla project. Learn more about Rhino at http://www.mozilla.org/rhino/ V8 – V8 is the open-source Google JavaScript engine written in C++. This is the JavaScript engine used by the Chrome web browser. You can download V8 and embed it in your project by visiting http://code.google.com/p/v8/ JScript – JScript is the JavaScript Script Engine used by Internet Explorer (up to but not including Internet Explorer 9), Windows Script Host, and Active Server Pages. Internet Explorer is still the most popular web browser. Therefore, I decided to focus on using the JScript Script Engine to execute JavaScript unit tests. Using the Microsoft Script Control There are two basic ways that you can pass JavaScript to the JScript Script Engine and execute the code: use the Microsoft Windows Script Interfaces or use the Microsoft Script Control. The difficult and proper way to execute JavaScript using the JScript Script Engine is to use the Microsoft Windows Script Interfaces. You can learn more about the Script Interfaces by visiting http://msdn.microsoft.com/en-us/library/t9d4xf28(VS.85).aspx The main disadvantage of using the Script Interfaces is that they are difficult to use from .NET. There is a great series of articles on using the Script Interfaces from C# located at http://www.drdobbs.com/184406028. I picked the easier alternative and used the Microsoft Script Control. The Microsoft Script Control is an ActiveX control that provides a higher level abstraction over the Window Script Interfaces. You can download the Microsoft Script Control from here: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=d7e31492-2595-49e6-8c02-1426fec693ac After you download the Microsoft Script Control, you need to add a reference to it to your project. Select the Visual Studio menu option Project, Add Reference to open the Add Reference dialog. Select the COM tab and add the Microsoft Script Control 1.0. Using the Script Control is easy. You call the Script Control AddCode() method to add JavaScript code to the Script Engine. Next, you call the Script Control Run() method to run a particular JavaScript function. The reference documentation for the Microsoft Script Control is located at the MSDN website: http://msdn.microsoft.com/en-us/library/aa227633%28v=vs.60%29.aspx Creating the JavaScript Code to Test To keep things simple, let’s imagine that you want to test the following JavaScript function named addNumbers() which simply adds two numbers together: MvcApplication1\Scripts\Math.js function addNumbers(a, b) { return 5; } Notice that the addNumbers() method always returns the value 5. Right-now, it will not pass a good unit test. Create this file and save it in your project with the name Math.js in your MVC project’s Scripts folder (Save the file in your actual MVC application and not your MVC test application). Creating the JavaScript Test Helper Class To make it easier to use the Microsoft Script Control in unit tests, we can create a helper class. This class contains two methods: LoadFile() – Loads a JavaScript file. Use this method to load the JavaScript file being tested or the JavaScript file containing the unit tests. ExecuteTest() – Executes the JavaScript code. Use this method to execute a JavaScript unit test. Here’s the code for the JavaScriptTestHelper class: JavaScriptTestHelper.cs   using System; using System.IO; using Microsoft.VisualStudio.TestTools.UnitTesting; using MSScriptControl; namespace MvcApplication1.Tests { public class JavaScriptTestHelper : IDisposable { private ScriptControl _sc; private TestContext _context; /// <summary> /// You need to use this helper with Unit Tests and not /// Basic Unit Tests because you need a Test Context /// </summary> /// <param name="testContext">Unit Test Test Context</param> public JavaScriptTestHelper(TestContext testContext) { if (testContext == null) { throw new ArgumentNullException("TestContext"); } _context = testContext; _sc = new ScriptControl(); _sc.Language = "JScript"; _sc.AllowUI = false; } /// <summary> /// Load the contents of a JavaScript file into the /// Script Engine. /// </summary> /// <param name="path">Path to JavaScript file</param> public void LoadFile(string path) { var fileContents = File.ReadAllText(path); _sc.AddCode(fileContents); } /// <summary> /// Pass the path of the test that you want to execute. /// </summary> /// <param name="testMethodName">JavaScript function name</param> public void ExecuteTest(string testMethodName) { dynamic result = null; try { result = _sc.Run(testMethodName, new object[] { }); } catch { var error = ((IScriptControl)_sc).Error; if (error != null) { var description = error.Description; var line = error.Line; var column = error.Column; var text = error.Text; var source = error.Source; if (_context != null) { var details = String.Format("{0} \r\nLine: {1} Column: {2}", source, line, column); _context.WriteLine(details); } } throw new AssertFailedException(error.Description); } } public void Dispose() { _sc = null; } } }     Notice that the JavaScriptTestHelper class requires a Test Context to be instantiated. For this reason, you can use the JavaScriptTestHelper only with a Visual Studio Unit Test and not a Basic Unit Test (These are two different types of Visual Studio project items). Add the JavaScriptTestHelper file to your MVC test application (for example, MvcApplication1.Tests). Creating the JavaScript Unit Test Next, we need to create the JavaScript unit test function that we will use to test the addNumbers() function. Create a folder in your MVC test project named JavaScriptTests and add the following JavaScript file to this folder: MvcApplication1.Tests\JavaScriptTests\MathTest.js /// <reference path="JavaScriptUnitTestFramework.js"/> function testAddNumbers() { // Act var result = addNumbers(1, 3); // Assert assert.areEqual(4, result, "addNumbers did not return right value!"); }   The testAddNumbers() function takes advantage of another JavaScript library named JavaScriptUnitTestFramework.js. This library contains all of the code necessary to make assertions. Add the following JavaScriptnitTestFramework.js to the same folder as the MathTest.js file: MvcApplication1.Tests\JavaScriptTests\JavaScriptUnitTestFramework.js var assert = { areEqual: function (expected, actual, message) { if (expected !== actual) { throw new Error("Expected value " + expected + " is not equal to " + actual + ". " + message); } } }; There is only one type of assertion supported by this file: the areEqual() assertion. Most likely, you would want to add additional types of assertions to this file to make it easier to write your JavaScript unit tests. Deploying the JavaScript Test Files This step is non-intuitive. When you use Visual Studio to run unit tests, Visual Studio creates a new folder and executes a copy of the files in your project. After you run your unit tests, your Visual Studio Solution will contain a new folder named TestResults that includes a subfolder for each test run. You need to configure Visual Studio to deploy your JavaScript files to the test run folder or Visual Studio won’t be able to find your JavaScript files when you execute your unit tests. You will get an error that looks something like this when you attempt to execute your unit tests: You can configure Visual Studio to deploy your JavaScript files by adding a Test Settings file to your Visual Studio Solution. It is important to understand that you need to add this file to your Visual Studio Solution and not a particular Visual Studio project. Right-click your Solution in the Solution Explorer window and select the menu option Add, New Item. Select the Test Settings item and click the Add button. After you create a Test Settings file for your solution, you can indicate that you want a particular folder to be deployed whenever you perform a test run. Select the menu option Test, Edit Test Settings to edit your test configuration file. Select the Deployment tab and select your MVC test project’s JavaScriptTest folder to deploy. Click the Apply button and the Close button to save the changes and close the dialog. Creating the Visual Studio Unit Test The very last step is to create the Visual Studio unit test (the MS Test unit test). Add a new unit test to your MVC test project by selecting the menu option Add New Item and selecting the Unit Test project item (Do not select the Basic Unit Test project item): The difference between a Basic Unit Test and a Unit Test is that a Unit Test includes a Test Context. We need this Test Context to use the JavaScriptTestHelper class that we created earlier. Enter the following test method for the new unit test: [TestMethod] public void TestAddNumbers() { var jsHelper = new JavaScriptTestHelper(this.TestContext); // Load JavaScript files jsHelper.LoadFile("JavaScriptUnitTestFramework.js"); jsHelper.LoadFile(@"..\..\..\MvcApplication1\Scripts\Math.js"); jsHelper.LoadFile("MathTest.js"); // Execute JavaScript Test jsHelper.ExecuteTest("testAddNumbers"); } This code uses the JavaScriptTestHelper to load three files: JavaScripUnitTestFramework.js – Contains the assert functions. Math.js – Contains the addNumbers() function from your MVC application which is being tested. MathTest.js – Contains the JavaScript unit test function. Next, the test method calls the JavaScriptTestHelper ExecuteTest() method to execute the testAddNumbers() JavaScript function. Running the Visual Studio JavaScript Unit Test After you complete all of the steps described above, you can execute the JavaScript unit test just like any other unit test. You can use the keyboard combination CTRL-R, CTRL-A to run all of the tests in the current Visual Studio Solution. Alternatively, you can use the buttons in the Visual Studio toolbar to run the tests: (Unfortunately, the Run All Impacted Tests button won’t work correctly because Visual Studio won’t detect that your JavaScript code has changed. Therefore, you should use either the Run Tests in Current Context or Run All Tests in Solution options instead.) The results of running the JavaScript tests appear side-by-side with the results of running the server tests in the Test Results window. For example, if you Run All Tests in Solution then you will get the following results: Notice that the TestAddNumbers() JavaScript test has failed. That is good because our addNumbers() function is hard-coded to always return the value 5. If you double-click the failing JavaScript test, you can view additional details such as the JavaScript error message and the line number of the JavaScript code that failed: Summary The goal of this blog entry was to explain an approach to creating JavaScript unit tests that can be easily integrated with Visual Studio and Visual Studio ALM. I described how you can use the Microsoft Script Control to execute JavaScript on the server. By taking advantage of the Microsoft Script Control, we were able to execute our JavaScript unit tests side-by-side with all of our other unit tests and view the results in the standard Visual Studio Test Results window. You can download the code discussed in this blog entry from here: http://StephenWalther.com/downloads/Blog/JavaScriptUnitTesting/JavaScriptUnitTests.zip Before running this code, you need to first install the Microsoft Script Control which you can download from here: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=d7e31492-2595-49e6-8c02-1426fec693ac

    Read the article

  • CHAT ROOMs 7 by 6

    - by user2939942
    I am looking for chatroom on one page with 7 loggedin users and 6+rows for say 42 users.these users will keep on adding wthnew users.Need urgent help.A PRETTY UNUSUAL Q FOR MOST OF U.What is MORE REQ new features: Usernames are unique to users currently chatting You can see a "currently chatting" user list There are multiple rooms for chatting <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> <title>Simpla Admin</title> <link rel="stylesheet" href="resources/css/reset.css" type="text/css" media="screen" /> <link rel="stylesheet" href="resources/css/style.css" type="text/css" media="screen" /> <link rel="stylesheet" href="resources/css/invalid.css" type="text/css" media="screen" /> <script type="text/javascript" src="resources/scripts/jquery-1.3.2.min.js"></script> <script type="text/javascript" src="resources/scripts/simpla.jquery.configuration.js"></script> <script type="text/javascript" src="resources/scripts/facebox.js"></script> <script type="text/javascript" src="resources/scripts/jquery.wysiwyg.js"></script> <script type="text/javascript" src="resources/scripts/jquery.datePicker.js"></script> <script type="text/javascript" src="resources/scripts/jquery.date.js"></script> <script language="JavaScript" type="text/javascript" src="suggest3.js"></script><script language="javascript"> function popitappup4() { var aid=document.a.cid.value; var url="followup.php?id="+aid; alert(url); newwindow=window.open(url,'name','height=480,width=480, scrollbars=yes'); if (window.focus) {newwindow.focus()} return false; } </script> <script type="text/javascript" src="highslide-with-html.js"></script> <link rel="stylesheet" type="text/css" href="highslide.css" /> <script type="text/javascript"> hs.graphicsDir = 'graphics/'; hs.outlineType = 'rounded-white'; hs.wrapperClassName = 'draggable-header'; </script> <link type="text/css" rel="stylesheet" media="all" href="css/chat.css" /> <link type="text/css" rel="stylesheet" media="all" href="css/screen.css" /> </head> <body onload="fnew()"><div id="body-wrapper"> <!-- Wrapper for the radial gradient background --> <div id="sidebar"> <link type="text/css" rel="stylesheet" media="all" href="css/chat.css" /> <link type="text/css" rel="stylesheet" media="all" href="css/screen.css" /> <script type="text/javascript" src="js/jquery.js"></script> <script type="text/javascript" src="js/chat.js"></script> <script type="text/javascript"> function fnew() { document.getElementById("psearch").focus(); } </script> <div id="sidebar-wrapper"> <!-- Sidebar with logo and menu --> <h1 id="sidebar-title"><a href="#"></a></h1> <!-- Logo (221px wide) --> <a href="#"><img id="logo" src="resources/images/logo.png" alt="Simpla Admin logo" /></a> <!-- Sidebar Profile links --> <form name="frm" action="opd_view1.php"> <table width="240" border="0" cellspacing="0" cellpadding="0"> <tr> <td width="210"><div align="right" style="font-size:22px; color:#FFFFFF"><b>OPD Search</b></div></td> <td width="30"><div align="right"></div></td> </tr> <tr> <td align="right">&nbsp;</td> <td align="right">&nbsp;</td> </tr> <tr> <td align="right"><div align="right"> <input type="text" name="psearch" id="psearch" class="text-input" style="width:45mm;" /> </div></td> <td align="right"><div align="right"></div></td> </tr> <tr> <td>&nbsp;</td> <td>&nbsp;</td> </tr> <tr> <td><div align="right"></div></td> <td><div align="right"></div></td> </tr> </table> </form> <div id="profile-links"> <a href="welcome.php" title="Sign Out" style="font-size:16px" ><b> </b></a> <br /> <a href="sample.php" title="Chat">Chat</a> </div></div> <!-- End #sidebar --> <div id="main-content"> <!-- Main Content Section with everything --> <noscript> <!-- Show a notification if the user has disabled javascript --> </noscript> <div style="width:100%; height: 600px; overflow-x: scroll; scrollbar-arrow-color: blue; scrollbar-face-color: #e7e7e7; scrollbar-3dlight-color: #a0a0a0; scrollbar-darkshadow-color: #888888; background-color:#FFFFFF "> <ul class="shortcut-buttons-set"> <!-- Page Head --> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drabhinit')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drabhinit</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drvarun')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drvarun</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('sameer')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>sameer</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drchetan')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drchetan</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('neema')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>neema</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drpriya')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drpriya</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drchhavi')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drchhavi</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drsanjay')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drsanjay</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('ruchi')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>ruchi</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drarchana')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drarchana</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drshraddha')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drshraddha</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('sunita')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>sunita</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('reshma')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>reshma</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('riya')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>riya</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drritesh')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drritesh</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('rachana')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>rachana</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('sunita')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>sunita</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('kavye')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>kavye</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('paridhi')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>paridhi</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('paridhi')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>paridhi</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drsonika')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drsonika</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('anny')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>anny</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('nitansh')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>nitansh</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drekta')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drekta</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drritesh')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drritesh</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('neeraj')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>neeraj</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('neeraj')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>neeraj</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drneha')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drneha</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('kirti')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>kirti</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drratna')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drratna</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drratana')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drratana</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drnoopur')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drnoopur</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('admin k')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>admin k</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('web')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>web</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drarti')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drarti</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drsaqib')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drsaqib</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('neelesh')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>neelesh</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('pooja')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>pooja</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drneha')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drneha</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drnupur')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drnupur</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('isha')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>isha</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('isha')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>isha</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drnamrata')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drnamrata</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('ashish')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>ashish</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('ambrish')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>ambrish</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drrashmi')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drrashmi</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drsapna')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drsapna</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('manisha')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>manisha</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('Isha')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>Isha</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drrashmi')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drrashmi</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('Dr Meghna')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>Dr Meghna</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('akanksha')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>akanksha</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drashish')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drashish</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drpriya')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drpriya</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drnitya')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drnitya</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drmanoj')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drmanoj</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('sonali')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>sonali</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drkhushbu')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drkhushbu</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drpriyanka')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drpriyanka</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drabhishek')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drabhishek</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drpoonam')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drpoonam</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drprachi')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drprachi</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drpeenal')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drpeenal</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('neerajpune')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>neerajpune</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('paridhipune')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>paridhipune</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('faeem')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>faeem</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('rahul')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>rahul</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('DrNeha')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>DrNeha</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drmrigendra')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drmrigendra</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('neetu')" rel="modal" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>neetu</span></a></li> <li> <a class="shortcut-button" href="javascript:void(0)" onClick="javascript:chatWith('drriteshpawar')" rel="modal" style=" background-color:#00FF00" ><span><img src="resources/images/icons/comment_48.png" alt="icon" width="48" height="48" /> <br/>drriteshpawar</span></a></li> </ul> </div> <script type="text/javascript" src="js/jquery.js"></script> <script type="text/javascript" src="js/chat.js"></script> <!-- End .shortcut-buttons-set --> <div class="clear"></div> <div class="clear"></div>

    Read the article

  • How to create a link to Nintex Start Workflow Page in the document set home page

    - by ybbest
    In this blog post, I’d like to show you how to create a link to start Nintex Workflow Page in the document set home page. 1. Firstly, you need to upload the latest version of jQuery to the style library of your team site. 2. Then, upload a text file to the style library for writing your own html and JavaScript 3. In the document set home page, insert a new content editor web part and link the text file you just upload. 4. Update the text file with the following content, you can download this file here. <script type="text/javascript" src="/Style%20Library/jquery-1.9.0.min.js"></script> <script type="text/javascript" src="/_layouts/sp.js"></script> <script type="text/javascript"> $(document).ready(function() { listItemId=getParameterByName("ID"); setTheWorkflowLink("YBBESTDocumentLibrary"); }); function buildWorkflowLink(webRelativeUrl,listId,itemId) { var workflowLink =webRelativeUrl+"_layouts/NintexWorkflow/StartWorkflow.aspx?list="+listId+"&ID="+itemId+"&WorkflowName=Start Approval"; return workflowLink; } function getParameterByName(name) { name = name.replace(/[\[]/, "\\\[").replace(/[\]]/, "\\\]"); var regexS = "[\\?&]" + name + "=([^&#]*)"; var regex = new RegExp(regexS); var results = regex.exec(window.location.search); if(results == null){ return ""; } else{ return decodeURIComponent(results[1].replace(/\+/g, " ")); } } function setTheWorkflowLink(listName) { var SPContext = new SP.ClientContext.get_current(); web = SPContext.get_web(); list = web.get_lists().getByTitle(listName); SPContext.load(web,"ServerRelativeUrl"); SPContext.load(list, 'Title', 'Id'); SPContext.executeQueryAsync(setTheWorkflowLink_Success, setTheWorkflowLink_Fail); } function setTheWorkflowLink_Success(sender, args) { var listId = list.get_id(); var listTitle = list.get_title(); var webRelativeUrl = web.get_serverRelativeUrl(); var startWorkflowLink=buildWorkflowLink(webRelativeUrl,listId,listItemId) $("a#submitLink").attr('href',startWorkflowLink); } function setTheWorkflowLink_Fail(sender, args) { alert("There is a problem setting up the submit exam approval link"); } </script> <a href="" target="_blank" id="submitLink"><span style="font-size:14pt">Start the approval process.</span></a> 5. Save your changes and go to the document set Item, you will see the link is on the home page now. Notes: 1. You can create a link to start the workflow using the following build dynamic string configuration: {Common:WebUrl}/_layouts/NintexWorkflow/StartWorkflow.aspx?list={Common:ListID}&ID={ItemProperty:ID}&WorkflowName=workflowname. With this link you will still need to click the start button, this is standard SharePoint behaviour and cannot be altered. References: http://connect.nintex.com/forums/27143/ShowThread.aspx How to use html and JavaScript in Content Editor web part in SharePoint2010

    Read the article

  • JavaScript: this

    - by bdukes
    JavaScript is a language steeped in juxtaposition.  It was made to “look like Java,” yet is dynamic and classless.  From this origin, we get the new operator and the this keyword.  You are probably used to this referring to the current instance of a class, so what could it mean in a language without classes? In JavaScript, this refers to the object off of which a function is referenced when it is invoked (unless it is invoked via call or apply). What this means is that this is not bound to your function, and can change depending on how your function is invoked. It also means that this changes when declaring a function inside another function (i.e. each function has its own this), such as when writing a callback. Let's see some of this in action: var obj = { count: 0, increment: function () { this.count += 1; }, logAfterTimeout = function () { setTimeout(function () { console.log(this.count); }, 1); } }; obj.increment(); console.log(obj.count); // 1 var increment = obj.increment; window.count = 'global count value: '; increment(); console.log(obj.count); // 1 console.log(window.count); // global count value: 1 var newObj = {count:50}; increment.call(newObj); console.log(newObj.count); // 51 obj.logAfterTimeout();// global count value: 1 obj.logAfterTimeout = function () { var proxiedFunction = $.proxy(function () { console.log(this.count); }, this); setTimeout(proxiedFunction, 1); }; obj.logAfterTimeout(); // 1 obj.logAfterTimeout = function () { var that = this; setTimeout(function () { console.log(that.count); }, 1); }; obj.logAfterTimeout(); // 1 The last couple of examples here demonstrate some methods for making sure you get the values you expect.  The first time logAfterTimeout is redefined, we use jQuery.proxy to create a new function which has its this permanently set to the passed in value (in this case, the current this).  The second time logAfterTimeout is redefined, we save the value of this in a variable (named that in this case, also often named self) and use the new variable in place of this. Now, all of this is to clarify what’s going on when you use this.  However, it’s pretty easy to avoid using this altogether in your code (especially in the way I’ve demonstrated above).  Instead of using this.count all over the place, it would have been much easier if I’d made count a variable instead of a property, and then I wouldn’t have to use this to refer to it.  var obj = (function () { var count = 0; return { increment: function () { count += 1; }, logAfterTimeout = function () { setTimeout(function () { console.log(count); }, 1); }, getCount: function () { return count; } }; }()); If you’re writing your code in this way, the main place you’ll run into issues with this is when handling DOM events (where this is the element on which the event occurred).  In that case, just be careful when using a callback within that event handler, that you’re not expecting this to still refer to the element (and use proxy or that/self if you need to refer to it). Finally, as demonstrated in the example, you can use call or apply on a function to set its this value.  This isn’t often needed, but you may also want to know that you can use apply to pass in an array of arguments to a function (e.g. console.log.apply(console, [1, 2, 3, 4])).

    Read the article

  • Find the item index in jCarouselLite

    - by stanley
    Hi all, I use jCarouselLite for scrolling text, I use and as the content for scrolling, I need to trigger a javascript event when it reaches at the end of the content(). I need to change the scroll content when it finishes scrolling previous content. I tried adding a call back function but it does'nt work. This is my code: $("#scrollDiv").jCarouselLite({ vertical: true, visible:3, hoverPause:true, scroll:3, auto:1, itemLastInCallback:changeItem, speed:5000 }); Certification Alerts-CertifyAssign cert_test_11 - cert_test_22_sub - sub_test_22 cert_adhoc - cert_adhoc_11 - stype1 Certification Alerts-CertifyReminder sales process001 - sub sales cert 2 - sales cert

    Read the article

  • Microsoft TypeScript : A Typed Superset of JavaScript

    - by shiju
    JavaScript is gradually becoming a ubiquitous programming language for the web, and the popularity of JavaScript is increasing day by day. Earlier, JavaScript was just a language for browser. But now, we can write JavaScript apps for browser, server and mobile. With the advent of Node.js, you can build scalable, high performance apps on the server with JavaScript. But many developers, especially developers who are working with static type languages, are hating the JavaScript language due to the lack of structuring and the maintainability problems of JavaScript. Microsoft TypeScript is trying to solve some problems of JavaScript when we are building scalable JavaScript apps. Microsoft TypeScript TypeScript is Microsoft's solution for writing scalable JavaScript programs with the help of Static Types, Interfaces, Modules and Classes along with greater tooling support. TypeScript is a typed superset of JavaScript that compiles to plain JavaScript. This would be more productive for developers who are coming from static type languages. You can write scalable JavaScript  apps in TypeScript with more productive and more maintainable manner, and later you can compiles to plain JavaScript which will be run on any browser and any OS. TypeScript will work with browser based JavaScript apps and JavaScript apps that following CommonJS specification. You can use TypeScript for building HTML 5 apps, Node.JS apps, WinRT apps. TypeScript is providing better tooling support with Visual Studio, Sublime Text, Vi, Emacs. Microsoft has open sourced its TypeScript languages on CodePlex at http://typescript.codeplex.com/    Install TypeScript You can install TypeScript compiler as a Node.js package via the NPM or you can install as a Visual Studio 2012 plug-in which will enable you better tooling support within the Visual Studio IDE. Since TypeScript is distributed as a Node.JS package, and it can be installed on other OS such as Linux and MacOS. The following command will install TypeScript compiler via an npm package for node.js npm install –g typescript TypeScript provides a Visual Studio 2012 plug-in as MSI file which will install TypeScript and also provides great tooling support within the Visual Studio, that lets the developers to write TypeScript apps with greater productivity and better maintainability. You can download the Visual Studio plug-in from here Building JavaScript  apps with TypeScript You can write typed version of JavaScript programs with TypeScript and then compiles it to plain JavaScript code. The beauty of the TypeScript is that it is already JavaScript and normal JavaScript programs are valid TypeScript programs, which means that you can write normal  JavaScript code and can use typed version of JavaScript whenever you want. TypeScript files are using extension .ts and this will be compiled using a compiler named tsc. The following is a sample program written in  TypeScript greeter.ts 1: class Greeter { 2: greeting: string; 3: constructor (message: string) { 4: this.greeting = message; 5: } 6: greet() { 7: return "Hello, " + this.greeting; 8: } 9: } 10:   11: var greeter = new Greeter("world"); 12:   13: var button = document.createElement('button') 14: button.innerText = "Say Hello" 15: button.onclick = function() { 16: alert(greeter.greet()) 17: } 18:   19: document.body.appendChild(button) .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; } The above program is compiling with the TypeScript compiler as shown in the below picture The TypeScript compiler will generate a JavaScript file after compiling the TypeScript program. If your TypeScript programs having any reference to other TypeScript files, it will automatically generate JavaScript files for the each referenced files. The following code block shows the compiled version of plain JavaScript  for the above greeter.ts greeter.js 1: var Greeter = (function () { 2: function Greeter(message) { 3: this.greeting = message; 4: } 5: Greeter.prototype.greet = function () { 6: return "Hello, " + this.greeting; 7: }; 8: return Greeter; 9: })(); 10: var greeter = new Greeter("world"); 11: var button = document.createElement('button'); 12: button.innerText = "Say Hello"; 13: button.onclick = function () { 14: alert(greeter.greet()); 15: }; 16: document.body.appendChild(button); .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; } Tooling Support with Visual Studio TypeScript is providing a plug-in for Visual Studio which will provide an excellent support for writing TypeScript  programs within the Visual Studio. The following screen shot shows the Visual Studio template for TypeScript apps   The following are the few screen shots of Visual Studio IDE for TypeScript apps. Summary TypeScript is Microsoft's solution for writing scalable JavaScript apps which will solve lot of problems involved in larger JavaScript apps. I hope that this solution will attract lot of developers who are really looking for writing maintainable structured code in JavaScript, without losing any productivity. TypeScript lets developers to write JavaScript apps with the help of Static Types, Interfaces, Modules and Classes and also providing better productivity. I am a passionate developer on Node.JS and would definitely try to use TypeScript for building Node.JS apps on the Windows Azure cloud. I am really excited about to writing Node.JS apps by using TypeScript, from my favorite development IDE Visual Studio. You can follow me on twitter at @shijucv

    Read the article

  • What useful things could a javaScript library provide?

    - by Delan Azabani
    In many of my answers I repeatedly urge users not to use JavaScript libraries like jQuery. I even wrote a blog post about the problems that using a library create. Some of these problems include holding back native standards development, keeping users comfortably using IE, and abstracting the developer from real JavaScript. If a site doesn't require IE as part of its audience, then how are libraries useful? The other popular browsers share extremely similar implementations and work well with things like JavaScript 1.6 arrays and AJAX. This is not a troll question, I'm truly wondering what they're useful for.

    Read the article

  • send different object value to different funtions

    - by user295189
    I have the code below. I want to send the value of value1 n.value1s = new Array(); n.value1sIDs = new Array(); n.value1sNames = new Array(); n.value1sColors = new Array(); n.descriptions = new Array(); to pg.loadLinkedvalue1s(n); and for value2 to pg.loadLinkedvalue2s(n); Howd I do that in javascript without haveing to rewrite the complete function please see the code below if(n.id == "row"){ n.rs = n.parentElement; if(n.rs.multiSelect == 0){ n.selected = 1; this.selectedRows = [ n ]; if(this.lastClicked && this.lastClicked != n){ selectionChanged = 1; this.lastClicked.selected = 0; this.lastClicked.style.color = "000099"; this.lastClicked.style.backgroundColor = ""; } } else { n.selected = n.selected ? 0 : 1; this.getSelectedRows(); } this.lastClicked = n; n.value1s = new Array(); n.value1sIDs = new Array(); n.value1sNames = new Array(); n.value1sColors = new Array(); n.descriptions = new Array(); n.value2s = new Array(); n.value2IDs = new Array(); n.value2Names = new Array(); n.value2Colors = new Array(); n.value2SortOrders = new Array(); n.value2Descriptions = new Array(); var value1s = myOfficeFunction.DOMArray(n.all.value1s.all.value1); var value2s = myOfficeFunction.DOMArray(n.all.value1s.all.value2); for(var i=0,j=0,k=1;i<vaue1s.length;i++){ n.sortOrders[j] = k++; n.vaue1s[j] = vaue1s[i].v; n.vaue1IDs[j] = vaue1s[i].i; n.vaue1Colors[j] = vaue1s[i].c; alert(n.vaue1Colors[j]); var vals = vaue1s[i].innerText.split(String.fromCharCode(127)); n.cptSortOrders[j] = k++; n.value2s[j] = value2s[i].v; n.value2IDs[j] = value2s[i].i; n.value2Colors[j] = value2s[i].c; var value2Vals = value2s[i].innerText.split(String.fromCharCode(127)); if(vals.length == 2){ alert(n.vaue1Colors[j]); n.vaue1Names[j] = vals[0]; n.descriptions[j++] = vals[1]; } if(value2Vals.length == 2){ n.value2Names[j] = cptVals[0]; alert(n.value2Names[j]); n.cptDescriptions[j++] = cptVals[1]; alert(n.cptDescriptions[j++]); } } //want to run this with value1 only pg.loadLinkedvalue1s(n); // want to run this with value2 only pg.loadLinkedvalue2s(n); }

    Read the article

  • Ancillary Objects: Separate Debug ELF Files For Solaris

    - by Ali Bahrami
    We introduced a new object ELF object type in Solaris 11 Update 1 called the Ancillary Object. This posting describes them, using material originally written during their development, the PSARC arc case, and the Solaris Linker and Libraries Manual. ELF objects contain allocable sections, which are mapped into memory at runtime, and non-allocable sections, which are present in the file for use by debuggers and observability tools, but which are not mapped or used at runtime. Typically, all of these sections exist within a single object file. Ancillary objects allow them to instead go into a separate file. There are different reasons given for wanting such a feature. One can debate whether the added complexity is worth the benefit, and in most cases it is not. However, one important case stands out — customers with very large 32-bit objects who are not ready or able to make the transition to 64-bits. We have customers who build extremely large 32-bit objects. Historically, the debug sections in these objects have used the stabs format, which is limited, but relatively compact. In recent years, the industry has transitioned to the powerful but verbose DWARF standard. In some cases, the size of these debug sections is large enough to push the total object file size past the fundamental 4GB limit for 32-bit ELF object files. The best, and ultimately only, solution to overly large objects is to transition to 64-bits. However, consider environments where: Hundreds of users may be executing the code on large shared systems. (32-bits use less memory and bus bandwidth, and on sparc runs just as fast as 64-bit code otherwise). Complex finely tuned code, where the original authors may no longer be available. Critical production code, that was expensive to qualify and bring online, and which is otherwise serving its intended purpose without issue. Users in these risk adverse and/or high scale categories have good reasons to push 32-bits objects to the limit before moving on. Ancillary objects offer these users a longer runway. Design The design of ancillary objects is intended to be simple, both to help human understanding when examining elfdump output, and to lower the bar for debuggers such as dbx to support them. The primary and ancillary objects have the same set of section headers, with the same names, in the same order (i.e. each section has the same index in both files). A single added section of type SHT_SUNW_ANCILLARY is added to both objects, containing information that allows a debugger to identify and validate both files relative to each other. Given one of these files, the ancillary section allows you to identify the other. Allocable sections go in the primary object, and non-allocable ones go into the ancillary object. A small set of non-allocable objects, notably the symbol table, are copied into both objects. As noted above, most sections are only written to one of the two objects, but both objects have the same section header array. The section header in the file that does not contain the section data is tagged with the SHF_SUNW_ABSENT section header flag to indicate its placeholder status. Compiler writers and others who produce objects can set the SUNW_SHF_PRIMARY section header flag to mark non-allocable sections that should go to the primary object rather than the ancillary. If you don't request an ancillary object, the Solaris ELF format is unchanged. Users who don't use ancillary objects do not pay for the feature. This is important, because they exist to serve a small subset of our users, and must not complicate the common case. If you do request an ancillary object, the runtime behavior of the primary object will be the same as that of a normal object. There is no added runtime cost. The primary and ancillary object together represent a logical single object. This is facilitated by the use of a single set of section headers. One can easily imagine a tool that can merge a primary and ancillary object into a single file, or the reverse. (Note that although this is an interesting intellectual exercise, we don't actually supply such a tool because there's little practical benefit above and beyond using ld to create the files). Among the benefits of this approach are: There is no need for per-file symbol tables to reflect the contents of each file. The same symbol table that would be produced for a standard object can be used. The section contents are identical in either case — there is no need to alter data to accommodate multiple files. It is very easy for a debugger to adapt to these new files, and the processing involved can be encapsulated in input/output routines. Most of the existing debugger implementation applies without modification. The limit of a 4GB 32-bit output object is now raised to 4GB of code, and 4GB of debug data. There is also the future possibility (not currently supported) to support multiple ancillary objects, each of which could contain up to 4GB of additional debug data. It must be noted however that the 32-bit DWARF debug format is itself inherently 32-bit limited, as it uses 32-bit offsets between debug sections, so the ability to employ multiple ancillary object files may not turn out to be useful. Using Ancillary Objects (From the Solaris Linker and Libraries Guide) By default, objects contain both allocable and non-allocable sections. Allocable sections are the sections that contain executable code and the data needed by that code at runtime. Non-allocable sections contain supplemental information that is not required to execute an object at runtime. These sections support the operation of debuggers and other observability tools. The non-allocable sections in an object are not loaded into memory at runtime by the operating system, and so, they have no impact on memory use or other aspects of runtime performance no matter their size. For convenience, both allocable and non-allocable sections are normally maintained in the same file. However, there are situations in which it can be useful to separate these sections. To reduce the size of objects in order to improve the speed at which they can be copied across wide area networks. To support fine grained debugging of highly optimized code requires considerable debug data. In modern systems, the debugging data can easily be larger than the code it describes. The size of a 32-bit object is limited to 4 Gbytes. In very large 32-bit objects, the debug data can cause this limit to be exceeded and prevent the creation of the object. To limit the exposure of internal implementation details. Traditionally, objects have been stripped of non-allocable sections in order to address these issues. Stripping is effective, but destroys data that might be needed later. The Solaris link-editor can instead write non-allocable sections to an ancillary object. This feature is enabled with the -z ancillary command line option. $ ld ... -z ancillary[=outfile] ...By default, the ancillary file is given the same name as the primary output object, with a .anc file extension. However, a different name can be provided by providing an outfile value to the -z ancillary option. When -z ancillary is specified, the link-editor performs the following actions. All allocable sections are written to the primary object. In addition, all non-allocable sections containing one or more input sections that have the SHF_SUNW_PRIMARY section header flag set are written to the primary object. All remaining non-allocable sections are written to the ancillary object. The following non-allocable sections are written to both the primary object and ancillary object. .shstrtab The section name string table. .symtab The full non-dynamic symbol table. .symtab_shndx The symbol table extended index section associated with .symtab. .strtab The non-dynamic string table associated with .symtab. .SUNW_ancillary Contains the information required to identify the primary and ancillary objects, and to identify the object being examined. The primary object and all ancillary objects contain the same array of sections headers. Each section has the same section index in every file. Although the primary and ancillary objects all define the same section headers, the data for most sections will be written to a single file as described above. If the data for a section is not present in a given file, the SHF_SUNW_ABSENT section header flag is set, and the sh_size field is 0. This organization makes it possible to acquire a full list of section headers, a complete symbol table, and a complete list of the primary and ancillary objects from either of the primary or ancillary objects. The following example illustrates the underlying implementation of ancillary objects. An ancillary object is created by adding the -z ancillary command line option to an otherwise normal compilation. The file utility shows that the result is an executable named a.out, and an associated ancillary object named a.out.anc. $ cat hello.c #include <stdio.h> int main(int argc, char **argv) { (void) printf("hello, world\n"); return (0); } $ cc -g -zancillary hello.c $ file a.out a.out.anc a.out: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, ancillary object a.out.anc a.out.anc: ELF 32-bit LSB ancillary 80386 Version 1, primary object a.out $ ./a.out hello worldThe resulting primary object is an ordinary executable that can be executed in the usual manner. It is no different at runtime than an executable built without the use of ancillary objects, and then stripped of non-allocable content using the strip or mcs commands. As previously described, the primary object and ancillary objects contain the same section headers. To see how this works, it is helpful to use the elfdump utility to display these section headers and compare them. The following table shows the section header information for a selection of headers from the previous link-edit example. Index Section Name Type Primary Flags Ancillary Flags Primary Size Ancillary Size 13 .text PROGBITS ALLOC EXECINSTR ALLOC EXECINSTR SUNW_ABSENT 0x131 0 20 .data PROGBITS WRITE ALLOC WRITE ALLOC SUNW_ABSENT 0x4c 0 21 .symtab SYMTAB 0 0 0x450 0x450 22 .strtab STRTAB STRINGS STRINGS 0x1ad 0x1ad 24 .debug_info PROGBITS SUNW_ABSENT 0 0 0x1a7 28 .shstrtab STRTAB STRINGS STRINGS 0x118 0x118 29 .SUNW_ancillary SUNW_ancillary 0 0 0x30 0x30 The data for most sections is only present in one of the two files, and absent from the other file. The SHF_SUNW_ABSENT section header flag is set when the data is absent. The data for allocable sections needed at runtime are found in the primary object. The data for non-allocable sections used for debugging but not needed at runtime are placed in the ancillary file. A small set of non-allocable sections are fully present in both files. These are the .SUNW_ancillary section used to relate the primary and ancillary objects together, the section name string table .shstrtab, as well as the symbol table.symtab, and its associated string table .strtab. It is possible to strip the symbol table from the primary object. A debugger that encounters an object without a symbol table can use the .SUNW_ancillary section to locate the ancillary object, and access the symbol contained within. The primary object, and all associated ancillary objects, contain a .SUNW_ancillary section that allows all the objects to be identified and related together. $ elfdump -T SUNW_ancillary a.out a.out.anc a.out: Ancillary Section: .SUNW_ancillary index tag value [0] ANC_SUNW_CHECKSUM 0x8724 [1] ANC_SUNW_MEMBER 0x1 a.out [2] ANC_SUNW_CHECKSUM 0x8724 [3] ANC_SUNW_MEMBER 0x1a3 a.out.anc [4] ANC_SUNW_CHECKSUM 0xfbe2 [5] ANC_SUNW_NULL 0 a.out.anc: Ancillary Section: .SUNW_ancillary index tag value [0] ANC_SUNW_CHECKSUM 0xfbe2 [1] ANC_SUNW_MEMBER 0x1 a.out [2] ANC_SUNW_CHECKSUM 0x8724 [3] ANC_SUNW_MEMBER 0x1a3 a.out.anc [4] ANC_SUNW_CHECKSUM 0xfbe2 [5] ANC_SUNW_NULL 0 The ancillary sections for both objects contain the same number of elements, and are identical except for the first element. Each object, starting with the primary object, is introduced with a MEMBER element that gives the file name, followed by a CHECKSUM that identifies the object. In this example, the primary object is a.out, and has a checksum of 0x8724. The ancillary object is a.out.anc, and has a checksum of 0xfbe2. The first element in a .SUNW_ancillary section, preceding the MEMBER element for the primary object, is always a CHECKSUM element, containing the checksum for the file being examined. The presence of a .SUNW_ancillary section in an object indicates that the object has associated ancillary objects. The names of the primary and all associated ancillary objects can be obtained from the ancillary section from any one of the files. It is possible to determine which file is being examined from the larger set of files by comparing the first checksum value to the checksum of each member that follows. Debugger Access and Use of Ancillary Objects Debuggers and other observability tools must merge the information found in the primary and ancillary object files in order to build a complete view of the object. This is equivalent to processing the information from a single file. This merging is simplified by the primary object and ancillary objects containing the same section headers, and a single symbol table. The following steps can be used by a debugger to assemble the information contained in these files. Starting with the primary object, or any of the ancillary objects, locate the .SUNW_ancillary section. The presence of this section identifies the object as part of an ancillary group, contains information that can be used to obtain a complete list of the files and determine which of those files is the one currently being examined. Create a section header array in memory, using the section header array from the object being examined as an initial template. Open and read each file identified by the .SUNW_ancillary section in turn. For each file, fill in the in-memory section header array with the information for each section that does not have the SHF_SUNW_ABSENT flag set. The result will be a complete in-memory copy of the section headers with pointers to the data for all sections. Once this information has been acquired, the debugger can proceed as it would in the single file case, to access and control the running program. Note - The ELF definition of ancillary objects provides for a single primary object, and an arbitrary number of ancillary objects. At this time, the Oracle Solaris link-editor only produces a single ancillary object containing all non-allocable sections. This may change in the future. Debuggers and other observability tools should be written to handle the general case of multiple ancillary objects. ELF Implementation Details (From the Solaris Linker and Libraries Guide) To implement ancillary objects, it was necessary to extend the ELF format to add a new object type (ET_SUNW_ANCILLARY), a new section type (SHT_SUNW_ANCILLARY), and 2 new section header flags (SHF_SUNW_ABSENT, SHF_SUNW_PRIMARY). In this section, I will detail these changes, in the form of diffs to the Solaris Linker and Libraries manual. Part IV ELF Application Binary Interface Chapter 13: Object File Format Object File Format Edit Note: This existing section at the beginning of the chapter describes the ELF header. There's a table of object file types, which now includes the new ET_SUNW_ANCILLARY type. e_type Identifies the object file type, as listed in the following table. NameValueMeaning ET_NONE0No file type ET_REL1Relocatable file ET_EXEC2Executable file ET_DYN3Shared object file ET_CORE4Core file ET_LOSUNW0xfefeStart operating system specific range ET_SUNW_ANCILLARY0xfefeAncillary object file ET_HISUNW0xfefdEnd operating system specific range ET_LOPROC0xff00Start processor-specific range ET_HIPROC0xffffEnd processor-specific range Sections Edit Note: This overview section defines the section header structure, and provides a high level description of known sections. It was updated to define the new SHF_SUNW_ABSENT and SHF_SUNW_PRIMARY flags and the new SHT_SUNW_ANCILLARY section. ... sh_type Categorizes the section's contents and semantics. Section types and their descriptions are listed in Table 13-5. sh_flags Sections support 1-bit flags that describe miscellaneous attributes. Flag definitions are listed in Table 13-8. ... Table 13-5 ELF Section Types, sh_type NameValue . . . SHT_LOSUNW0x6fffffee SHT_SUNW_ancillary0x6fffffee . . . ... SHT_LOSUNW - SHT_HISUNW Values in this inclusive range are reserved for Oracle Solaris OS semantics. SHT_SUNW_ANCILLARY Present when a given object is part of a group of ancillary objects. Contains information required to identify all the files that make up the group. See Ancillary Section. ... Table 13-8 ELF Section Attribute Flags NameValue . . . SHF_MASKOS0x0ff00000 SHF_SUNW_NODISCARD0x00100000 SHF_SUNW_ABSENT0x00200000 SHF_SUNW_PRIMARY0x00400000 SHF_MASKPROC0xf0000000 . . . ... SHF_SUNW_ABSENT Indicates that the data for this section is not present in this file. When ancillary objects are created, the primary object and any ancillary objects, will all have the same section header array, to facilitate merging them to form a complete view of the object, and to allow them to use the same symbol tables. Each file contains a subset of the section data. The data for allocable sections is written to the primary object while the data for non-allocable sections is written to an ancillary file. The SHF_SUNW_ABSENT flag is used to indicate that the data for the section is not present in the object being examined. When the SHF_SUNW_ABSENT flag is set, the sh_size field of the section header must be 0. An application encountering an SHF_SUNW_ABSENT section can choose to ignore the section, or to search for the section data within one of the related ancillary files. SHF_SUNW_PRIMARY The default behavior when ancillary objects are created is to write all allocable sections to the primary object and all non-allocable sections to the ancillary objects. The SHF_SUNW_PRIMARY flag overrides this behavior. Any output section containing one more input section with the SHF_SUNW_PRIMARY flag set is written to the primary object without regard for its allocable status. ... Two members in the section header, sh_link, and sh_info, hold special information, depending on section type. Table 13-9 ELF sh_link and sh_info Interpretation sh_typesh_linksh_info . . . SHT_SUNW_ANCILLARY The section header index of the associated string table. 0 . . . Special Sections Edit Note: This section describes the sections used in Solaris ELF objects, using the types defined in the previous description of section types. It was updated to define the new .SUNW_ancillary (SHT_SUNW_ANCILLARY) section. Various sections hold program and control information. Sections in the following table are used by the system and have the indicated types and attributes. Table 13-10 ELF Special Sections NameTypeAttribute . . . .SUNW_ancillarySHT_SUNW_ancillaryNone . . . ... .SUNW_ancillary Present when a given object is part of a group of ancillary objects. Contains information required to identify all the files that make up the group. See Ancillary Section for details. ... Ancillary Section Edit Note: This new section provides the format reference describing the layout of a .SUNW_ancillary section and the meaning of the various tags. Note that these sections use the same tag/value concept used for dynamic and capabilities sections, and will be familiar to anyone used to working with ELF. In addition to the primary output object, the Solaris link-editor can produce one or more ancillary objects. Ancillary objects contain non-allocable sections that would normally be written to the primary object. When ancillary objects are produced, the primary object and all of the associated ancillary objects contain a SHT_SUNW_ancillary section, containing information that identifies these related objects. Given any one object from such a group, the ancillary section provides the information needed to identify and interpret the others. This section contains an array of the following structures. See sys/elf.h. typedef struct { Elf32_Word a_tag; union { Elf32_Word a_val; Elf32_Addr a_ptr; } a_un; } Elf32_Ancillary; typedef struct { Elf64_Xword a_tag; union { Elf64_Xword a_val; Elf64_Addr a_ptr; } a_un; } Elf64_Ancillary; For each object with this type, a_tag controls the interpretation of a_un. a_val These objects represent integer values with various interpretations. a_ptr These objects represent file offsets or addresses. The following ancillary tags exist. Table 13-NEW1 ELF Ancillary Array Tags NameValuea_un ANC_SUNW_NULL0Ignored ANC_SUNW_CHECKSUM1a_val ANC_SUNW_MEMBER2a_ptr ANC_SUNW_NULL Marks the end of the ancillary section. ANC_SUNW_CHECKSUM Provides the checksum for a file in the c_val element. When ANC_SUNW_CHECKSUM precedes the first instance of ANC_SUNW_MEMBER, it provides the checksum for the object from which the ancillary section is being read. When it follows an ANC_SUNW_MEMBER tag, it provides the checksum for that member. ANC_SUNW_MEMBER Specifies an object name. The a_ptr element contains the string table offset of a null-terminated string, that provides the file name. An ancillary section must always contain an ANC_SUNW_CHECKSUM before the first instance of ANC_SUNW_MEMBER, identifying the current object. Following that, there should be an ANC_SUNW_MEMBER for each object that makes up the complete set of objects. Each ANC_SUNW_MEMBER should be followed by an ANC_SUNW_CHECKSUM for that object. A typical ancillary section will therefore be structured as: TagMeaning ANC_SUNW_CHECKSUMChecksum of this object ANC_SUNW_MEMBERName of object #1 ANC_SUNW_CHECKSUMChecksum for object #1 . . . ANC_SUNW_MEMBERName of object N ANC_SUNW_CHECKSUMChecksum for object N ANC_SUNW_NULL An object can therefore identify itself by comparing the initial ANC_SUNW_CHECKSUM to each of the ones that follow, until it finds a match. Related Other Work The GNU developers have also encountered the need/desire to support separate debug information files, and use the solution detailed at http://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html. At the current time, the separate debug file is constructed by building the standard object first, and then copying the debug data out of it in a separate post processing step, Hence, it is limited to a total of 4GB of code and debug data, just as a single object file would be. They are aware of this, and I have seen online comments indicating that they may add direct support for generating these separate files to their link-editor. It is worth noting that the GNU objcopy utility is available on Solaris, and that the Studio dbx debugger is able to use these GNU style separate debug files even on Solaris. Although this is interesting in terms giving Linux users a familiar environment on Solaris, the 4GB limit means it is not an answer to the problem of very large 32-bit objects. We have also encountered issues with objcopy not understanding Solaris-specific ELF sections, when using this approach. The GNU community also has a current effort to adapt their DWARF debug sections in order to move them to separate files before passing the relocatable objects to the linker. The details of Project Fission can be found at http://gcc.gnu.org/wiki/DebugFission. The goal of this project appears to be to reduce the amount of data seen by the link-editor. The primary effort revolves around moving DWARF data to separate .dwo files so that the link-editor never encounters them. The details of modifying the DWARF data to be usable in this form are involved — please see the above URL for details.

    Read the article

  • JavaScript - Settting property on Object in Image load function, property not set once outside funct

    - by Sunday Ironfoot
    Sometimes JavaScript doesn't make sense to me, consider the following code that generates a photo mosaic based on x/y tiles. I'm trying to set a .Done property to true once each Mosaic image has been downloaded, but it's always false for some reason, what am I doing wrong? var tileData = []; function generate() { var image = new Image(); image.onload = function() { // Build up the 'tileData' array with tile objects from this Image for (var i = 0; i < tileData.length; i++) { var tile = tileData[i]; var tileImage = new Image(); tileImage.onload = function() { // Do something with this tile Image tile.Done = true; }; tileImage.src = tile.ImageUrl; } }; image.src = 'Penguins.jpg'; tryDisplayMosaic(); } function tryDisplayMosaic() { setTimeout(function() { for (var i = 0; i < tileData.length; i++) { var tile = tileData[i]; if (!tile.Done) { tryDisplayMosaic(); return; } } // If we get here then all the tiles have been downloaded alert('All images downloaded'); }, 2000); } Now for some reason the .Done property on the tile object is always false, even though it is explicitly being set to true inside tileImage.onload = function(). And I can ensure you that this function DOES get called because I've placed an alert() call inside it. Right now it's just stuck inside an infinite loop calling tryDisplayMosaic() constantly. Also if I place a loop just before tryDisplayMosaic() is called, and in that loop I set .Done = true, then .Done property is true and alert('All images downloaded'); will get called.

    Read the article

  • Writing a Javascript library that is code-completion and code-inspection friendly

    - by Vivin Paliath
    I recently made my own Javascript library and I initially used the following pattern: var myLibrary = (function () { var someProp = "..."; function someFunc() { ... } function someFunc2() { ... } return { func: someFunc, fun2: someFunc2, prop: someProp; } }()); The problem with this is that I can't really use code completion because the IDE doesn't know about the properties that the function literal is returning (I'm using IntelliJ IDEA 9 by the way). I've looked at jQuery code and tried to do this: (function(window, undefined) { var myLibrary = (function () { var someProp = "..."; function someFunc() { ... } function someFunc2() { ... } return { func: someFunc, fun2: someFunc2, prop: someProp; } }()); window.myLibrary = myLibrary; }(window)); I tried this, but now I have a different problem. The IDE doesn't really pick up on myLibrary either. The way I'm solving the problem now is this way: var myLibrary = { func: function() { }, func2: function() { }, prop: "" }; myLibrary = (function () { var someProp = "..."; function someFunc() { ... } function someFunc2() { ... } return { func: someFunc, fun2: someFunc2, prop: someProp; } }()); But that seems kinda clunky, and I can't exactly figure out how jQuery is doing it. Another question I have is how to handle functions with arbitrary numbers of parameters. For example, jQuery.bind can take 2 or 3 parameters, and the IDE doesn't seem to complain. I tried to do the same thing with my library, where a function could take 0 arguments or 1 argument. However, the IDE complains and warns that the correct number of parameters aren't being sent in. How do I handle this?

    Read the article

  • JavaScript Browser Hacks

    Recently during one of my client side scripting classes, I was trying to show my students some basic examples of JavaScript as an introduction to the language.  My first basic example was to show an alert box using JavaScript via the address bar. The student’s reaction to my browser hack example really caught me off guard in a good way. After programming with a language for close to 10 years you start to lose the "Awe Cool!" effect that new learners of a language experience when writing code. New learns of JavaScript are the reason why I created this post. Please enjoy. Note: Place JavaScript in to address bar and then press the enter key. Example 1: JavaScript Alert box displaying My name: John Doe Javascript:alert('My name: \n John Doe') ; Example 2: JavaScript alert box displaying name entered by user. javascript:alert('My name: \n ' + prompt('Enter Name','Name')) ; Example 3: JavaScript alert box displaying name entered by user, and then displays the length of the name. javascript:var name= prompt('Enter Name','Name'); alert('My name: \n ' + name); alert(name.length); If you notice, the address bar will execute JavaScript on the current page loaded in the browser using the Document Object Model (DOM). Additionally, the address bar will allow multiple lines to be executed sequentially even though all of the code is contained within one line due to the fact that the JavaScript interpreter uses the “;” to indicate where a line of ends and a new one begins. After doing a little more research on the topic of JavaScript Browser Hacks I found a few other cool JavaScript hacks which I will list below. Example 4: Make any webpage editableSource: http://www.openjason.com/2008/09/02/browser-hack-make-any-web-page-editable/ javascript:document.body.contentEditable='true'; document.designMode='on'; void 0; Example 5: CHINESE DRAGON DANCING Source: http://nzeyi.wordpress.com/2009/06/01/dwrajaxjavascript-hacks-the-secrets-of-javascript-in-the-adress-bar/ javascript:R=0;x1=0.1;y1=0.05;x2=0.25;y2=0.24;x3=1.6; y3=0.24;x4=300;y4=200;x5=300;y5=200;DI=document.links; DIL=DI.length;A=function(){for(i=0;i-DIL;i++){DI[i].style. position='absolute';DI[i].style.left=Math.sin(R*x1+i*x2+x3)*x4+ x5;DI[i].style.top=Math.cos(R*y1+i*y2+y3)*y4+y5}R++;}; setInterval('A()',5);void(0); Example 6: Reveal content stored in password protected fields javascript:(function(){var s,F,j,f,i; s = “”; F = document.forms; for(j=0; j Example 7: Force user to close browser windowSource: http://forums.digitalpoint.com/showthread.php?t=767053 javascript:while(1){alert('Restart your brower to close this box!')} Learn more about JavaScript Browser Hacks.

    Read the article

  • javascript csv validation

    - by Hulk
    How to check for comma separated values in a text box and raise an alert if not found. And there is should be characters in it like A,B,C,D function validate() { //validate text box; } <input type="text" id="val" >A,B,C,D</input> <input type="button" id="save" onclick="validate()"> Thanks.

    Read the article

  • call the id in javascript

    - by user295189
    I have a span like this <span id="selectedTests" class="emrFG"> <span id="lblSelectedTests" class="emrHDR" style="top:3;left:6;font-size:8pt;">Selections</span> <span class="emrHDR" style="top:3;left:190;font-size:8pt;">Tests</span> <div id="recordSet" style="top:19;height:112;width:444;"></div> </span> The span shows some rows of data and I want to call those rows individually by using document.all method. How would I do that?

    Read the article

  • Has Javascript developed beyond what it was originally designed to do?

    - by Elliot Bonneville
    I've been talking with a friend about the purpose of Javascript, when and how it should be used, etc. He quoted that: JavaScript was designed to add interactivity to HTML pages [...] JavaScript gives HTML designers a programming tool HTML authors are normally not programmers, but JavaScript is a scripting language with a very simple syntax! Almost anyone can put small "snippets" of code into their HTML pages JavaScript can react to events A JavaScript can be set to execute when something happens, like when a page has finished loading or when a user clicks on an HTML element JavaScript can read and write HTML elements A JavaScript can read and change the content of an HTML element JavaScript can be used to validate data A JavaScript can be used to validate form data before it is submitted to a server. This saves the server from extra processing JavaScript can be used to detect the visitor's browser - A JavaScript can be used to detect the visitor's browser, and - depending on the browser - load another page specifically designed for that browser. JavaScript can be used to create cookies - A JavaScript can be used to store and retrieve information on the visitor's computer. However, it seems like Javascript's getting used to do a lot more than these days. My friend also advocates against using Javascript's OOP functionality, claiming that "you shouldn't be processing data, merely validating." Is Javascript really limited to validating data and making flashy graphics on a web page? He goes on to claim "you shouldn't be attempting to access databases through javascript" and also says " in general you don't want to be doing your heavy lifting in javascript". I can't say I agree with his opinion, but I'd like to get some more input on this. So, my question: Has Javascript evolved from the definition above to something more powerful, has the way we use it changed, or am I just plain wrong? While I realize this is a subjective question, I can't find any more information on it, so a few links would be good, if nothing else. I'm not looking for a debate, just an answer.

    Read the article

  • Is there a javascript library that contains a rich set of very high level commonly used functions?

    - by bobo
    I find that many high level functions are missing in most well-known javascript libraries such as jquery, YUI...etc. Taking string manipulation as an example, startsWith, endsWith, contains, lTrim, rTrim, trim, isNullOrEmpty...etc. These function are actually very common ones. I would like to know if there exists a javascript library/ plugin of a javascript library that fills these gaps (including but not limited to string manipulation)? It would be great if the library does not override the prototype.

    Read the article

  • How do I convert some ugly inline javascript into a function?

    - by Taylor
    I've got a form with various inputs that by default have no value. When a user changes one or more of the inputs all values including the blank ones are used in the URL GET string when submitted. So to clean it up I've got some javascript that removes the inputs before submission. It works well enough but I was wondering how to put this in a js function or tidy it up. Seems a bit messy to have it all clumped in to an onclick. Plus i'm going to be adding more so there will be quite a few. Here's the relevant code. There are 3 seperate lines for 3 seperate inputs. The first part of the line has a value that refers to the inputs ID ("mf","cf","bf","pf") and the second part of the line refers to the parent div ("dmf","dcf", etc). The first part is an example of the input structure... echo "<div id='dmf'><select id='mf' name='mFilter'>"; This part is the submit and js... echo "<input type='submit' value='Apply' onclick='javascript: if (document.getElementById(\"mf\").value==\"\") { document.getElementById(\"dmf\").innerHTML=\"\"; } if (document.getElementById(\"cf\").value==\"\") { document.getElementById(\"dcf\").innerHTML=\"\"; } if (document.getElementById(\"bf\").value==\"\") { document.getElementById(\"dbf\").innerHTML=\"\"; } if (document.getElementById(\"pf\").value==\"\") { document.getElementById(\"dpf\").innerHTML=\"\"; } ' />"; I have pretty much zero javascript knowledge so help turning this in to a neater function or similar would be much appreciated.

    Read the article

  • Much Ado About Nothing: Stub Objects

    - by user9154181
    The Solaris 11 link-editor (ld) contains support for a new type of object that we call a stub object. A stub object is a shared object, built entirely from mapfiles, that supplies the same linking interface as the real object, while containing no code or data. Stub objects cannot be executed — the runtime linker will kill any process that attempts to load one. However, you can link to a stub object as a dependency, allowing the stub to act as a proxy for the real version of the object. You may well wonder if there is a point to producing an object that contains nothing but linking interface. As it turns out, stub objects are very useful for building large bodies of code such as Solaris. In the last year, we've had considerable success in applying them to one of our oldest and thorniest build problems. In this discussion, I will describe how we came to invent these objects, and how we apply them to building Solaris. This posting explains where the idea for stub objects came from, and details our long and twisty journey from hallway idea to standard link-editor feature. I expect that these details are mainly of interest to those who work on Solaris and its makefiles, those who have done so in the past, and those who work with other similar bodies of code. A subsequent posting will omit the history and background details, and instead discuss how to build and use stub objects. If you are mainly interested in what stub objects are, and don't care about the underlying software war stories, I encourage you to skip ahead. The Long Road To Stubs This all started for me with an email discussion in May of 2008, regarding a change request that was filed in 2002, entitled: 4631488 lib/Makefile is too patient: .WAITs should be reduced This CR encapsulates a number of cronic issues with Solaris builds: We build Solaris with a parallel make (dmake) that tries to build as much of the code base in parallel as possible. There is a lot of code to build, and we've long made use of parallelized builds to get the job done quicker. This is even more important in today's world of massively multicore hardware. Solaris contains a large number of executables and shared objects. Executables depend on shared objects, and shared objects can depend on each other. Before you can build an object, you need to ensure that the objects it needs have been built. This implies a need for serialization, which is in direct opposition to the desire to build everying in parallel. To accurately build objects in the right order requires an accurate set of make rules defining the things that depend on each other. This sounds simple, but the reality is quite complex. In practice, having programmers explicitly specify these dependencies is a losing strategy: It's really hard to get right. It's really easy to get it wrong and never know it because things build anyway. Even if you get it right, it won't stay that way, because dependencies between objects can change over time, and make cannot help you detect such drifing. You won't know that you got it wrong until the builds break. That can be a long time after the change that triggered the breakage happened, making it hard to connect the cause and the effect. Usually this happens just before a release, when the pressure is on, its hard to think calmly, and there is no time for deep fixes. As a poor compromise, the libraries in core Solaris were built using a set of grossly incomplete hand written rules, supplemented with a number of dmake .WAIT directives used to group the libraries into sets of non-interacting groups that can be built in parallel because we think they don't depend on each other. From time to time, someone will suggest that we could analyze the built objects themselves to determine their dependencies and then generate make rules based on those relationships. This is possible, but but there are complications that limit the usefulness of that approach: To analyze an object, you have to build it first. This is a classic chicken and egg scenario. You could analyze the results of a previous build, but then you're not necessarily going to get accurate rules for the current code. It should be possible to build the code without having a built workspace available. The analysis will take time, and remember that we're constantly trying to make builds faster, not slower. By definition, such an approach will always be approximate, and therefore only incremantally more accurate than the hand written rules described above. The hand written rules are fast and cheap, while this idea is slow and complex, so we stayed with the hand written approach. Solaris was built that way, essentially forever, because these are genuinely difficult problems that had no easy answer. The makefiles were full of build races in which the right outcomes happened reliably for years until a new machine or a change in build server workload upset the accidental balance of things. After figuring out what had happened, you'd mutter "How did that ever work?", add another incomplete and soon to be inaccurate make dependency rule to the system, and move on. This was not a satisfying solution, as we tend to be perfectionists in the Solaris group, but we didn't have a better answer. It worked well enough, approximately. And so it went for years. We needed a different approach — a new idea to cut the Gordian Knot. In that discussion from May 2008, my fellow linker-alien Rod Evans had the initial spark that lead us to a game changing series of realizations: The link-editor is used to link objects together, but it only uses the ELF metadata in the object, consisting of symbol tables, ELF versioning sections, and similar data. Notably, it does not look at, or understand, the machine code that makes an object useful at runtime. If you had an object that only contained the ELF metadata for a dependency, but not the code or data, the link-editor would find it equally useful for linking, and would never know the difference. Call it a stub object. In the core Solaris OS, we require all objects to be built with a link-editor mapfile that describes all of its publically available functions and data. Could we build a stub object using the mapfile for the real object? It ought to be very fast to build stub objects, as there are no input objects to process. Unlike the real object, stub objects would not actually require any dependencies, and so, all of the stubs for the entire system could be built in parallel. When building the real objects, one could link against the stub objects instead of the real dependencies. This means that all the real objects can be built built in parallel too, without any serialization. We could replace a system that requires perfect makefile rules with a system that requires no ordering rules whatsoever. The results would be considerably more robust. We immediately realized that this idea had potential, but also that there were many details to sort out, lots of work to do, and that perhaps it wouldn't really pan out. As is often the case, it would be necessary to do the work and see how it turned out. Following that conversation, I set about trying to build a stub object. We determined that a faithful stub has to do the following: Present the same set of global symbols, with the same ELF versioning, as the real object. Functions are simple — it suffices to have a symbol of the right type, possibly, but not necessarily, referencing a null function in its text segment. Copy relocations make data more complicated to stub. The possibility of a copy relocation means that when you create a stub, the data symbols must have the actual size of the real data. Any error in this will go uncaught at link time, and will cause tragic failures at runtime that are very hard to diagnose. For reasons too obscure to go into here, involving tentative symbols, it is also important that the data reside in bss, or not, matching its placement in the real object. If the real object has more than one symbol pointing at the same data item, we call these aliased symbols. All data symbols in the stub object must exhibit the same aliasing as the real object. We imagined the stub library feature working as follows: A command line option to ld tells it to produce a stub rather than a real object. In this mode, only mapfiles are examined, and any object or shared libraries on the command line are are ignored. The extra information needed (function or data, size, and bss details) would be added to the mapfile. When building the real object instead of the stub, the extra information for building stubs would be validated against the resulting object to ensure that they match. In exploring these ideas, I immediately run headfirst into the reality of the original mapfile syntax, a subject that I would later write about as The Problem(s) With Solaris SVR4 Link-Editor Mapfiles. The idea of extending that poor language was a non-starter. Until a better mapfile syntax became available, which seemed unlikely in 2008, the solution could not involve extentions to the mapfile syntax. Instead, we cooked up the idea (hack) of augmenting mapfiles with stylized comments that would carry the necessary information. A typical definition might look like: # DATA(i386) __iob 0x3c0 # DATA(amd64,sparcv9) __iob 0xa00 # DATA(sparc) __iob 0x140 iob; A further problem then became clear: If we can't extend the mapfile syntax, then there's no good way to extend ld with an option to produce stub objects, and to validate them against the real objects. The idea of having ld read comments in a mapfile and parse them for content is an unacceptable hack. The entire point of comments is that they are strictly for the human reader, and explicitly ignored by the tool. Taking all of these speed bumps into account, I made a new plan: A perl script reads the mapfiles, generates some small C glue code to produce empty functions and data definitions, compiles and links the stub object from the generated glue code, and then deletes the generated glue code. Another perl script used after both objects have been built, to compare the real and stub objects, using data from elfdump, and validate that they present the same linking interface. By June 2008, I had written the above, and generated a stub object for libc. It was a useful prototype process to go through, and it allowed me to explore the ideas at a deep level. Ultimately though, the result was unsatisfactory as a basis for real product. There were so many issues: The use of stylized comments were fine for a prototype, but not close to professional enough for shipping product. The idea of having to document and support it was a large concern. The ideal solution for stub objects really does involve having the link-editor accept the same arguments used to build the real object, augmented with a single extra command line option. Any other solution, such as our prototype script, will require makefiles to be modified in deeper ways to support building stubs, and so, will raise barriers to converting existing code. A validation script that rederives what the linker knew when it built an object will always be at a disadvantage relative to the actual linker that did the work. A stub object should be identifyable as such. In the prototype, there was no tag or other metadata that would let you know that they weren't real objects. Being able to identify a stub object in this way means that the file command can tell you what it is, and that the runtime linker can refuse to try and run a program that loads one. At that point, we needed to apply this prototype to building Solaris. As you might imagine, the task of modifying all the makefiles in the core Solaris code base in order to do this is a massive task, and not something you'd enter into lightly. The quality of the prototype just wasn't good enough to justify that sort of time commitment, so I tabled the project, putting it on my list of long term things to think about, and moved on to other work. It would sit there for a couple of years. Semi-coincidentally, one of the projects I tacked after that was to create a new mapfile syntax for the Solaris link-editor. We had wanted to do something about the old mapfile syntax for many years. Others before me had done some paper designs, and a great deal of thought had already gone into the features it should, and should not have, but for various reasons things had never moved beyond the idea stage. When I joined Sun in late 2005, I got involved in reviewing those things and thinking about the problem. Now in 2008, fresh from relearning for the Nth time why the old mapfile syntax was a huge impediment to linker progress, it seemed like the right time to tackle the mapfile issue. Paving the way for proper stub object support was not the driving force behind that effort, but I certainly had them in mind as I moved forward. The new mapfile syntax, which we call version 2, integrated into Nevada build snv_135 in in February 2010: 6916788 ld version 2 mapfile syntax PSARC/2009/688 Human readable and extensible ld mapfile syntax In order to prove that the new mapfile syntax was adequate for general purpose use, I had also done an overhaul of the ON consolidation to convert all mapfiles to use the new syntax, and put checks in place that would ensure that no use of the old syntax would creep back in. That work went back into snv_144 in June 2010: 6916796 OSnet mapfiles should use version 2 link-editor syntax That was a big putback, modifying 517 files, adding 18 new files, and removing 110 old ones. I would have done this putback anyway, as the work was already done, and the benefits of human readable syntax are obvious. However, among the justifications listed in CR 6916796 was this We anticipate adding additional features to the new mapfile language that will be applicable to ON, and which will require all sharable object mapfiles to use the new syntax. I never explained what those additional features were, and no one asked. It was premature to say so, but this was a reference to stub objects. By that point, I had already put together a working prototype link-editor with the necessary support for stub objects. I was pleased to find that building stubs was indeed very fast. On my desktop system (Ultra 24), an amd64 stub for libc can can be built in a fraction of a second: % ptime ld -64 -z stub -o stubs/libc.so.1 -G -hlibc.so.1 \ -ztext -zdefs -Bdirect ... real 0.019708910 user 0.010101680 sys 0.008528431 In order to go from prototype to integrated link-editor feature, I knew that I would need to prove that stub objects were valuable. And to do that, I knew that I'd have to switch the Solaris ON consolidation to use stub objects and evaluate the outcome. And in order to do that experiment, ON would first need to be converted to version 2 mapfiles. Sub-mission accomplished. Normally when you design a new feature, you can devise reasonably small tests to show it works, and then deploy it incrementally, letting it prove its value as it goes. The entire point of stub objects however was to demonstrate that they could be successfully applied to an extremely large and complex code base, and specifically to solve the Solaris build issues detailed above. There was no way to finesse the matter — in order to move ahead, I would have to successfully use stub objects to build the entire ON consolidation and demonstrate their value. In software, the need to boil the ocean can often be a warning sign that things are trending in the wrong direction. Conversely, sometimes progress demands that you build something large and new all at once. A big win, or a big loss — sometimes all you can do is try it and see what happens. And so, I spent some time staring at ON makefiles trying to get a handle on how things work, and how they'd have to change. It's a big and messy world, full of complex interactions, unspecified dependencies, special cases, and knowledge of arcane makefile features... ...and so, I backed away, put it down for a few months and did other work... ...until the fall, when I felt like it was time to stop thinking and pondering (some would say stalling) and get on with it. Without stubs, the following gives a simplified high level view of how Solaris is built: An initially empty directory known as the proto, and referenced via the ROOT makefile macro is established to receive the files that make up the Solaris distribution. A top level setup rule creates the proto area, and performs operations needed to initialize the workspace so that the main build operations can be launched, such as copying needed header files into the proto area. Parallel builds are launched to build the kernel (usr/src/uts), libraries (usr/src/lib), and commands. The install makefile target builds each item and delivers a copy to the proto area. All libraries and executables link against the objects previously installed in the proto, implying the need to synchronize the order in which things are built. Subsequent passes run lint, and do packaging. Given this structure, the additions to use stub objects are: A new second proto area is established, known as the stub proto and referenced via the STUBROOT makefile macro. The stub proto has the same structure as the real proto, but is used to hold stub objects. All files in the real proto are delivered as part of the Solaris product. In contrast, the stub proto is used to build the product, and then thrown away. A new target is added to library Makefiles called stub. This rule builds the stub objects. The ld command is designed so that you can build a stub object using the same ld command line you'd use to build the real object, with the addition of a single -z stub option. This means that the makefile rules for building the stub objects are very similar to those used to build the real objects, and many existing makefile definitions can be shared between them. A new target is added to the Makefiles called stubinstall which delivers the stub objects built by the stub rule into the stub proto. These rules reuse much of existing plumbing used by the existing install rule. The setup rule runs stubinstall over the entire lib subtree as part of its initialization. All libraries and executables link against the objects in the stub proto rather than the main proto, and can therefore be built in parallel without any synchronization. There was no small way to try this that would yield meaningful results. I would have to take a leap of faith and edit approximately 1850 makefiles and 300 mapfiles first, trusting that it would all work out. Once the editing was done, I'd type make and see what happened. This took about 6 weeks to do, and there were many dark days when I'd question the entire project, or struggle to understand some of the many twisted and complex situations I'd uncover in the makefiles. I even found a couple of new issues that required changes to the new stub object related code I'd added to ld. With a substantial amount of encouragement and help from some key people in the Solaris group, I eventually got the editing done and stub objects for the entire workspace built. I found that my desktop system could build all the stub objects in the workspace in roughly a minute. This was great news, as it meant that use of the feature is effectively free — no one was likely to notice or care about the cost of building them. After another week of typing make, fixing whatever failed, and doing it again, I succeeded in getting a complete build! The next step was to remove all of the make rules and .WAIT statements dedicated to controlling the order in which libraries under usr/src/lib are built. This came together pretty quickly, and after a few more speed bumps, I had a workspace that built cleanly and looked like something you might actually be able to integrate someday. This was a significant milestone, but there was still much left to do. I turned to doing full nightly builds. Every type of build (open, closed, OpenSolaris, export, domestic) had to be tried. Each type failed in a new and unique way, requiring some thinking and rework. As things came together, I became aware of things that could have been done better, simpler, or cleaner, and those things also required some rethinking, the seeking of wisdom from others, and some rework. After another couple of weeks, it was in close to final form. My focus turned towards the end game and integration. This was a huge workspace, and needed to go back soon, before changes in the gate would made merging increasingly difficult. At this point, I knew that the stub objects had greatly simplified the makefile logic and uncovered a number of race conditions, some of which had been there for years. I assumed that the builds were faster too, so I did some builds intended to quantify the speedup in build time that resulted from this approach. It had never occurred to me that there might not be one. And so, I was very surprised to find that the wall clock build times for a stock ON workspace were essentially identical to the times for my stub library enabled version! This is why it is important to always measure, and not just to assume. One can tell from first principles, based on all those removed dependency rules in the library makefile, that the stub object version of ON gives dmake considerably more opportunities to overlap library construction. Some hypothesis were proposed, and shot down: Could we have disabled dmakes parallel feature? No, a quick check showed things being build in parallel. It was suggested that we might be I/O bound, and so, the threads would be mostly idle. That's a plausible explanation, but system stats didn't really support it. Plus, the timing between the stub and non-stub cases were just too suspiciously identical. Are our machines already handling as much parallelism as they are capable of, and unable to exploit these additional opportunities? Once again, we didn't see the evidence to back this up. Eventually, a more plausible and obvious reason emerged: We build the libraries and commands (usr/src/lib, usr/src/cmd) in parallel with the kernel (usr/src/uts). The kernel is the long leg in that race, and so, wall clock measurements of build time are essentially showing how long it takes to build uts. Although it would have been nice to post a huge speedup immediately, we can take solace in knowing that stub objects simplify the makefiles and reduce the possibility of race conditions. The next step in reducing build time should be to find ways to reduce or overlap the uts part of the builds. When that leg of the build becomes shorter, then the increased parallelism in the libs and commands will pay additional dividends. Until then, we'll just have to settle for simpler and more robust. And so, I integrated the link-editor support for creating stub objects into snv_153 (November 2010) with 6993877 ld should produce stub objects PSARC/2010/397 ELF Stub Objects followed by the work to convert the ON consolidation in snv_161 (February 2011) with 7009826 OSnet should use stub objects 4631488 lib/Makefile is too patient: .WAITs should be reduced This was a huge putback, with 2108 modified files, 8 new files, and 2 removed files. Due to the size, I was allowed a window after snv_160 closed in which to do the putback. It went pretty smoothly for something this big, a few more preexisting race conditions would be discovered and addressed over the next few weeks, and things have been quiet since then. Conclusions and Looking Forward Solaris has been built with stub objects since February. The fact that developers no longer specify the order in which libraries are built has been a big success, and we've eliminated an entire class of build error. That's not to say that there are no build races left in the ON makefiles, but we've taken a substantial bite out of the problem while generally simplifying and improving things. The introduction of a stub proto area has also opened some interesting new possibilities for other build improvements. As this article has become quite long, and as those uses do not involve stub objects, I will defer that discussion to a future article.

    Read the article

  • Pluralsight Meet the Author Podcast on Structuring JavaScript Code

    - by dwahlin
    I had the opportunity to talk with Fritz Onion from Pluralsight about one of my recent courses titled Structuring JavaScript Code for one of their Meet the Author podcasts. We talked about why JavaScript patterns are important for building more re-useable and maintainable apps, pros and cons of different patterns, and how to go about picking a pattern as a project is started. The course provides a solid walk-through of converting what I call “Function Spaghetti Code” into more modular code that’s easier to maintain, more re-useable, and less susceptible to naming conflicts. Patterns covered in the course include the Prototype Pattern, Revealing Module Pattern, and Revealing Prototype Pattern along with several other tips and techniques that can be used. Meet the Author:  Dan Wahlin on Structuring JavaScript Code   The transcript from the podcast is shown below: [Fritz]  Hello, this is Fritz Onion with another Pluralsight author interview. Today we’re talking with Dan Wahlin about his new course, Structuring JavaScript Code. Hi, Dan, it’s good to have you with us today. [Dan]  Thanks for having me, Fritz. [Fritz]  So, Dan, your new course, which came out in December of 2011 called Structuring JavaScript Code, goes into several patterns of usage in JavaScript as well as ways of organizing your code and what struck me about it was all the different techniques you described for encapsulating your code. I was wondering if you could give us just a little insight into what your motivation was for creating this course and sort of why you decided to write it and record it. [Dan]  Sure. So, I got started with JavaScript back in the mid 90s. In fact, back in the days when browsers that most people haven’t heard of were out and we had JavaScript but it wasn’t great. I was on a project in the late 90s that was heavy, heavy JavaScript and we pretty much did what I call in the course function spaghetti code where you just have function after function, there’s no rhyme or reason to how those functions are structured, they just kind of flow and it’s a little bit hard to do maintenance on it, you really don’t get a lot of reuse as far as from an object perspective. And so coming from an object-oriented background in JAVA and C#, I wanted to put something together that highlighted kind of the new way if you will of writing JavaScript because most people start out just writing functions and there’s nothing with that, it works, but it’s definitely not a real reusable solution. So the course is really all about how to move from just kind of function after function after function to the world of more encapsulated code and more reusable and hopefully better maintenance in the process. [Fritz]  So I am sure a lot of people have had similar experiences with their JavaScript code and will be looking forward to seeing what types of patterns you’ve put forth. Now, a couple I noticed in your course one is you start off with the prototype pattern. Do you want to describe sort of what problem that solves and how you go about using it within JavaScript? [Dan]  Sure. So, the patterns that are covered such as the prototype pattern and the revealing module pattern just as two examples, you know, show these kind of three things that I harp on throughout the course of encapsulation, better maintenance, reuse, those types of things. The prototype pattern specifically though has a couple kind of pros over some of the other patterns and that is the ability to extend your code without touching source code and what I mean by that is let’s say you’re writing a library that you know either other teammates or other people just out there on the Internet in general are going to be using. With the prototype pattern, you can actually write your code in such a way that we’re leveraging the JavaScript property and by doing that now you can extend my code that I wrote without touching my source code script or you can even override my code and perform some new functionality. Again, without touching my code.  And so you get kind of the benefit of the almost like inheritance or overriding in object oriented languages with this prototype pattern and it makes it kind of attractive that way definitely from a maintenance standpoint because, you know, you don’t want to modify a script I wrote because I might roll out version 2 and now you’d have to track where you change things and it gets a little tricky. So with this you just override those pieces or extend them and get that functionality and that’s kind of some of the benefits that that pattern offers out of the box. [Fritz]  And then the revealing module pattern, how does that differ from the prototype pattern and what problem does that solve differently? [Dan]  Yeah, so the prototype pattern and there’s another one that’s kind of really closely lined with revealing module pattern called the revealing prototype pattern and it also uses the prototype key word but it’s very similar to the one you just asked about the revealing module pattern. [Fritz]  Okay. [Dan]  This is a really popular one out there. In fact, we did a project for Microsoft that was very, very heavy JavaScript. It was an HMTL5 jQuery type app and we use this pattern for most of the structure if you will for the JavaScript code and what it does in a nutshell is allows you to get that encapsulation so you have really a single function wrapper that wraps all your other child functions but it gives you the ability to do public versus private members and this is kind of a sort of debate out there on the web. Some people feel that all JavaScript code should just be directly accessible and others kind of like to be able to hide their, truly their private stuff and a lot of people do that. You just put an underscore in front of your field or your variable name or your function name and that kind of is the defacto way to say hey, this is private. With the revealing module pattern you can do the equivalent of what objective oriented languages do and actually have private members that you literally can’t get to as an external consumer of the JavaScript code and then you can expose only those members that you want to be public. Now, you don’t get the benefit though of the prototype feature, which is I can’t easily extend the revealing module pattern type code if you don’t like something I’m doing, chances are you’re probably going to have to tweak my code to fix that because we’re not leveraging prototyping but in situations where you’re writing apps that are very specific to a given target app, you know, it’s not a library, it’s not going to be used in other apps all over the place, it’s a pattern I actually like a lot, it’s very simple to get going and then if you do like that public/private feature, it’s available to you. [Fritz]  Yeah, that’s interesting. So it’s almost, you can either go private by convention just by using a standard naming convention or you can actually enforce it by using the prototype pattern. [Dan]  Yeah, that’s exactly right. [Fritz]  So one of the things that I know I run across in JavaScript and I’m curious to get your take on is we do have all these different techniques of encapsulation and each one is really quite different when you’re using closures versus simply, you know, referencing member variables and adding them to your objects that the syntax changes with each pattern and the usage changes. So what would you recommend for people starting out in a brand new JavaScript project? Should they all sort of decide beforehand on what patterns they’re going to stick to or do you change it based on what part of the library you’re working on? I know that’s one of the points of confusion in this space. [Dan]  Yeah, it’s a great question. In fact, I just had a company ask me about that. So which one do I pick and, of course, there’s not one answer fits all. [Fritz]  Right. [Dan]  So it really depends what you just said is absolutely in my opinion correct, which is I think as a, especially if you’re on a team or even if you’re just an individual a team of one, you should go through and pick out which pattern for this particular project you think is best. Now if it were me, here’s kind of the way I think of it. If I were writing a let’s say base library that several web apps are going to use or even one, but I know that there’s going to be some pieces that I’m not really sure on right now as I’m writing I and I know people might want to hook in that and have some better extension points, then I would look at either the prototype pattern or the revealing prototype. Now, really just a real quick summation between the two the revealing prototype also gives you that public/private stuff like the revealing module pattern does whereas the prototype pattern does not but both of the prototype patterns do give you the benefit of that extension or that hook capability. So, if I were writing a library that I need people to override things or I’m not even sure what I need them to override, I want them to have that option, I’d probably pick a prototype, one of the prototype patterns. If I’m writing some code that is very unique to the app and it’s kind of a one off for this app which is what I think a lot of people are kind of in that mode as writing custom apps for customers, then my personal preference is the revealing module pattern you could always go with the module pattern as well which is very close but I think the revealing module patterns a little bit cleaner and we go through that in the course and explain kind of the syntax there and the differences. [Fritz]  Great, that makes a lot of sense. [Fritz]  I appreciate you taking the time, Dan, and I hope everyone takes a chance to look at your course and sort of make these decisions for themselves in their next JavaScript project. Dan’s course is, Structuring JavaScript Code and it’s available now in the Pluralsight Library. So, thank you very much, Dan. [Dan]  Thanks for having me again.

    Read the article

  • ASP.NET JavaScript Routing for ASP.NET MVC–Constraints

    - by zowens
    If you haven’t had a look at my previous post about ASP.NET routing, go ahead and check it out before you read this post: http://weblogs.asp.net/zowens/archive/2010/12/20/asp-net-mvc-javascript-routing.aspx And the code is here: https://github.com/zowens/ASP.NET-MVC-JavaScript-Routing   Anyways, this post is about routing constraints. A routing constraint is essentially a way for the routing engine to filter out route patterns based on the day from the URL. For example, if I have a route where all the parameters are required, I could use a constraint on the required parameters to say that the parameter is non-empty. Here’s what the constraint would look like: Notice that this is a class that inherits from IRouteConstraint, which is an interface provided by System.Web.Routing. The match method returns true if the value is a match (and can be further processed by the routing rules) or false if it does not match (and the route will be matched further along the route collection). Because routing constraints are so essential to the route matching process, it was important that they be part of my JavaScript routing engine. But the problem is that we need to somehow represent the constraint in JavaScript. I made a design decision early on that you MUST put this constraint into JavaScript to match a route. I didn’t want to have server interaction for the URL generation, like I’ve seen in so many applications. While this is easy to maintain, it causes maintenance issues in my opinion. So the way constraints work in JavaScript is that the constraint as an object type definition is set on the route manager. When a route is created, a new instance of the constraint is created with the specific parameter. In its current form the constraint function MUST return a function that takes the route data and will return true or false. You will see the NotEmpty constraint in a bit. Another piece to the puzzle is that you can have the JavaScript exist as a string in your application that is pulled in when the routing JavaScript code is generated. There is a simple interface, IJavaScriptAddition, that I have added that will be used to output custom JavaScript. Let’s put it all together. Here is the NotEmpty constraint. There’s a few things at work here. The constraint is called “notEmpty” in JavaScript. When you add the constraint to a parameter in your C# code, the route manager generator will look for the JsConstraint attribute to look for the name of the constraint type name and fallback to the class name. For example, if I didn’t apply the “JsConstraint” attribute, the constraint would be called “NotEmpty”. The JavaScript code essentially adds a function to the “constraintTypeDefs” object on the “notEmpty” property (this is how constraints are added to routes). The function returns another function that will be invoked with routing data. Here’s how you would use the NotEmpty constraint in C# and it will work with the JavaScript routing generator. The only catch to using route constraints currently is that the following is not supported: The constraint will work in C# but is not supported by my JavaScript routing engine. (I take pull requests so if you’d like this… go ahead and implement it).   I just wanted to take this post to explain a little bit about the background on constraints. I am looking at expanding the current functionality, but for now this is a good start. Thanks for all the support with the JavaScript router. Keep the feedback coming!

    Read the article

  • Repeated calls with random Javascript append to the URL

    - by cjk
    I keep getting calls to my server where there is random Javascript appended on the end of lots of the calls, e.g.: /UI/Includes/JavaScript/).length)&&e.error( /UI/Includes/JavaScript/,C,!1),a.addEventListener( /UI/Includes/JavaScript/),l=b.createDocumentFragment(),m=b.documentElement,n=m.firstChild,o=b.createElement( /UI/Includes/JavaScript/&&a.getAttributeNode( /UI/Includes/JavaScript/&&a.firstChild.getAttribute( /UI/Includes/JavaScript/).replace(bd, /UI/Includes/JavaScript/)),a.getElementsByTagName( The user agent is always this: Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+2.0.50727) I have jQuery, Modernizr and other JS and originally thought that some browser was messing up it's JS calls, however this particular IP address hasn't requested any images so I'm wondering if it is some kind of attack. Is this a common occurence?

    Read the article

  • JavaScript or PHP based WYSIWYG vector based image editor

    - by Jeroen Pluimers
    For a PHP based site of a client, I'm looking for a vector based image editor that allows: end user creation of vectored images consisting of objects supports upload of bitmap images to be used as objects inside the vector image supports adding text objects to add to the vector image, and change properties (font name, font style, font size) of the text objects preferably supports layering or grouping of objects inside the vector image integrates nicely with a PHP based site (so a PHP or JavaScript library is preferred) can store the vector image in SVG, EPS or PDF Both commercial and FOSS solutions are OK. Any idea where to find such a library? --jeroen

    Read the article

1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >