DOCSLIB.ORG

HTML Client Development

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
HTML Client Development HTML Client Development Target API: Lightstreamer HTML Client v. 5.0 Last updated: 13/06/2011 Table of contents 1 INTRODUCTION..............................................................................................................3 2 HTML CLIENT DEVELOPMENT.............................................................................................4 2.1 Deployment Architecture..................................................................................4 2.2 Site Architecture..............................................................................................5 2.2.1 A traditional site containing one Push-Page only.................................................6 2.2.2 A traditional site with multiple Push-Pages navigated serially..............................6 2.2.3 A traditional site with multiple Push-Pages navigated in parallel..........................6 2.2.4 A full-blown AJAX site.......................................................................................9 2.2.5 HTML5 offline applications................................................................................9 2.3 The Push-Pages.............................................................................................10 2.4 The Screen Tables..........................................................................................14 2.4.1 OverwriteTable...............................................................................................14 2.4.2 ScrollTable.....................................................................................................15 2.4.3 DynaScrollTable.............................................................................................16 2.4.4 MetapushTable...............................................................................................17 2.4.5 DynaMetapushTable.......................................................................................18 2.4.6 MultiDynaMetapushTable................................................................................20 2.5 Error Handlers................................................................................................21 - 2 - 1 Introduction This document provides a conceptual introduction to the development of Lightstreamer Web Clients based on HTML and JavaScript. A full JavaScript API reference is available both online or within the software distribution: – Online JSDoc: http://www.lightstreamer.com/docs/client_web_jsdoc/index.html – Bundled JSDoc: “Lightstreamer/DOCS-SDKs/sdk_client_html/doc/API-reference-index.html” - 3 - 2 HTML Client Development The Lightstreamer HTML Client (also known as the Lightstreamer Web Client) is a set of JavaScript libraries and HTML files that can be included into any Web site in order to make it “Lightstreamer-enabled”, that is, ready to receive real-time updates pushed from Lightstreamer Server. The resources to be deployed on the web server are available under the “Lightstreamer/DOCS- SDKs/sdk_client_html/lib” directory of Lightstreamer distribution and comprise the following files: version.number (the version of Lightstreamer Web Client) build.number (the build number of Lightstreamer Web Client) compatibility_version.number (the required minimum version of Lightstreamer Server) lsblank.html lscommons.js lsengine.html lsengine.js lsform.html lspushpage.js These files must not be modified. They should be copied to a directory of your web server (for example the “/LS” directory in the root of your web site). 2.1 Deployment Architecture For demo purpose, Lightstreamer Server contains an internal web server that is able to serve static web resources. This makes it simple to distribute out-of-the-box demos (such as the StockList Demo) and to get started with Lightstreamer development. But for actual projects and production scenarios, it is highly recommended that an external web server is used (because Lightstreamer is optimized for pushing real-time data, not for serving static pages). Typically, a Lightstreamer Server and any common web server (e.g. Apache, Tomcat, IIS or any other web server of your choice) are deployed in the DMZ network. Lightstreamer Server gets the data and metadata from the back-end servers that are protected by the second firewall. The web browser gets the static web pages, as usual, from your web server, then it connects to Lightstreamer Server to receive the flow of real-time updates. Of course, both of the servers can be clustered for fail-over and load balancing. - 4 - In order for the system to work properly in this scenario (Lightstreamer Server + external web server), it is fundamental that both the servers share the same domain name in the DNS. For example: www.mycompany.com: the web server name push.mycompany.com: the Lightstreamer Server name TIP: If you are developing on a stand-alone PC (so you probably have Lightstreamer Server and the web server on the same machine on different ports), in an environment without a domain, you can simulate the final environment by editing the host file of your PC. For example, in a Windows environment, you will edit the “C:\WINDOWS\system32\drivers\etc\hosts” file and add something like: 127.0.0.1 www.mycompany.com 127.0.0.1 push.mycompany.com NOTE: In any case, when launching your web application inside a browser, you will always need to specify the full URL, e.g.: http://www.mycompany.com/myapplication and not a shortcut such as: http://localhost/myapplication or http://127.0.0.1/myapplication or http://mypcname/my-application. DEPLOYING A WEB APP ON AN EXTERNAL WEB SERVER After installing and running Lightstreamer Server from the distribution package, you will be able to see several demos, which are pre-installed in the internal web server. In order to deploy any demo on an external web server and get acquainted with the actions needed to embrace this deployment scenario for your own applications, please see the follow the “Lightstreamer/pages/demos/HOW_TO_DEPLOY_ON_YOUR_WEB_SERVER.TXT” document. 2.2 Site Architecture Each page of the site that is destined to receive real-time updates from Lightstreamer is defined as a Push-Page. The site can contain as many Push-Pages as needed, which can be displayed both concurrently and in sequence. All of the Push-Pages will be part of the same Lightstreamer session and will share a common LightstreamerEngine object. A LightstreamerEngine object is a JavaScript object that encapsulates the logic used to communicate with Lightstreamer Server and to dispatch the events to the Push-Pages. LightstreamerEngine handles the physical connections to the Server, including the permanent stream connection. The LightstreamerEngine object must live inside a Push-Page (under the hood, a LightstreamerEngine object creates a hidden iframe inside the Push-Page and loads a page inside it; in the JSDoc this is referred to as the “Engine page”). The Push-Page that hosts the LightstreamerEngine object is called the Master Push-Page. NOTE: The protocol used to connect to Lightstreamer Server is always the same used to download the Master Push-Page. So if the Master Push-Page is downloaded through HTTP, then HTTP will be used for all the connections to Lightstreamer Server. If the Master Push-Page is downloaded through HTTPS, all the connections to Lightstreamer Server will use HTTPS. There exist different ways to integrate the Master Push-Page in the site, depending on the site architecture and on the navigation style. The following sections discuss some alternative strategies (by “traditional site” we mean any site that does not take advantage of the AJAX paradigm). Please consider those are just examples of possible integration architectures and other strategies are possible. - 5 - 2.2.1 A traditional site containing one Push-Page only In this scenario there is only one page in the site that needs to display real-time data. That means there is only one Push-Page and it is a Master Push-Page Each time the user navigates to the Master Push-Page, a Lightstreamer session is initiated. When the user leaves the Push-Page, the Lightstreamer session is closed. 2.2.2 A traditional site with multiple Push-Pages navigated serially Multiple Push-Pages exist in the site but only one at a time is displayed (e.g. no pop-up Push-Pages are used; no Push-Pages in different frames are present). It could be decided that each Push-Page is a Master Push-Page (because only one Master Push-Page at a time exists, due to serial navigation). The effect is that a Lightstreamer session is initiated and closed each time the user enters and exits a Push-Page. A better strategy for this scenario is to use a frameset, as explained in paragraph A of section 2.2.3 (see Example 2). 2.2.3 A traditional site with multiple Push-Pages navigated in parallel Multiple Push-Pages exist in the site and two or more Push-Pages at a time can be displayed (this is typically accomplished by using pop-up windows or multiple frames). To support this scenarios several solutions are possible: A) Using a FRAMESET An HTML frameset is leveraged in order to add a permanent frame that contains the Master Push-Page. Other Push-Pages contained in frames or pop-ups can be created and destroyed through the navigation, but all of them use the same LightstreamerEngine that is part of the permanent Master Push-Page. The Master Push-Page frame can be a visible or an invisible (i.e. zero-sized) frame. Example 1. The site already contains a frameset in the index.htm page, that loads two frames (menubar.htm and homebody.htm). A first option is to
Load more

Recommended publications
  • Stable/Build) • --Port PORT - Set the PORT Number (Default: 8000)
    Pyodide Release 0.18.1 unknown Sep 16, 2021 CONTENTS 1 Using Pyodide 3 1.1 Getting started..............................................3 1.2 Downloading and deploying Pyodide..................................6 1.3 Using Pyodide..............................................7 1.4 Loading packages............................................ 12 1.5 Type translations............................................. 14 1.6 Pyodide Python compatibility...................................... 25 1.7 API Reference.............................................. 26 1.8 Frequently Asked Questions....................................... 50 2 Development 55 2.1 Building from sources.......................................... 55 2.2 Creating a Pyodide package....................................... 57 2.3 How to Contribute............................................ 64 2.4 Testing and benchmarking........................................ 74 2.5 Interactive Debugging.......................................... 76 3 Project 79 3.1 About Pyodide.............................................. 79 3.2 Roadmap................................................. 80 3.3 Code of Conduct............................................. 82 3.4 Governance and Decision-making.................................... 83 3.5 Change Log............................................... 85 3.6 Related Projects............................................. 95 4 Indices and tables 97 Python Module Index 99 Index 101 i ii Pyodide, Release 0.18.1 Python with the scientific stack, compiled to WebAssembly.
    [Show full text]
  • Javascript API Deprecation in the Wild: a First Assessment
    JavaScript API Deprecation in the Wild: A First Assessment Romulo Nascimento, Aline Brito, Andre Hora, Eduardo Figueiredo Department of Computer Science Federal University of Minas Gerais, Brazil romulonascimento, alinebrito, andrehora,figueiredo @dcc.ufmg.br { } Abstract—Building an application using third-party libraries of our knowledge, there are no detailed studies regarding API is a common practice in software development. As any other deprecation in the JavaScript ecosystem. software system, code libraries and their APIs evolve over JavaScript has become extremely popular over the last years. time. In order to help version migration and ensure backward According to the Stack Overflow 2019 Developer Survey1, compatibility, a recommended practice during development is to deprecate API. Although studies have been conducted to JavaScript is the most popular programming language in this investigate deprecation in some programming languages, such as platform for the seventh consecutive year. GitHub also reports Java and C#, there are no detailed studies on API deprecation that JavaScript is the most popular language in terms of unique in the JavaScript ecosystem. This paper provides an initial contributors to both public and private repositories2. The npm assessment of API deprecation in JavaScript by analyzing 50 platform, the largest JavaScript package manager, states on popular software projects. Initial results suggest that the use of 3 deprecation mechanisms in JavaScript packages is low. However, their latest survey that 99% of JavaScript developers rely on wefindfive different ways that developers use to deprecate API npm to ease the management of their project dependencies. in the studied projects. Among these solutions, deprecation utility This survey also points out the massive growth in npm usage (i.e., any sort of function specially written to aid deprecation) and that started about 5 years ago.
    [Show full text]
  • Javascript Client Guide
    JavaScript Client Guide Target API: Lightstreamer JavaScript Client v. 6.1.4 Last updated: 15/07/2014 Table of contents 1 INTRODUCTION................................................................................................................3 2 JAVASCRIPT CLIENT DEVELOPMENT.........................................................................................4 2.1 Deployment Architecture..................................................................................4 2.1.1 Deployment and Browsers................................................................................4 2.2 Site/Application Architecture.............................................................................5 2.3 The LightstreamerClient...................................................................................6 2.3.1 Using an AMD loader........................................................................................7 2.3.2 Using Global Objects........................................................................................9 2.3.3 Name Clashes................................................................................................10 2.3.4 LightstreamerClient in a Web Worker...............................................................11 2.3.5 The Node.js case............................................................................................12 2.4 The Subscription Listeners..............................................................................13 2.4.1 StaticGrid.......................................................................................................13
    [Show full text]
  • Prevent Jsdoc from Writting to File
    Prevent Jsdoc From Writting To File Anatole await pallidly if assonant Jamie dwining or doublings. Napoleon bolts his depurators remilitarizing vainly, but condyloid Tabby never lament so slantwise. Baking-hot and uliginous Torry unitings her propulsion snog while Douglas buffetings some retirers Tuesdays. Jsdoc comment log message object from file will be ignored if true, the same port files to gpudb instances of a function? Redirect output parameters can prevent jsdoc from writting to file you want for messages from response to search. Official documentation for addition project. No nulls will be generated for nullable columns. The new functionality is it is when accessing properties at once all have not only in scope objects and then. If a chain of an uppercase character from. Suggests any typing for a loan eligibility when no longer would be from an object can prevent unauthorized access control characters and! An application message, please sign speak for my weekly Dev Mastery newsletter below. The box of degrees the pasture is rotated clockwise. Used within another number of systematically improving health related status. This page to read and fetch the file to. Many different from jsdoc file to prevent execution. You from that can be an exception of information icon when introducing visual studio code blocks is synchronous, but in more we prevent jsdoc from writting to file is there any! There by some special cases that appear flat the whole framework. Linting rules for Backbone. Form Objects and Functions pane. Nothing in a point me know it could restrict it can prevent jsdoc? Optional parameters for a given client.
    [Show full text]
  • Vasili Korol
    Vasili Korol Senior Software Developer Odense, Denmark Age: 35 mob.: +45 20 68 50 23 Married, have son (born 2010) e-mail: [email protected] ​ Personal Statement ⚬ Strong IT skills (16+ years of versatile experience) ⚬ Background in physics research ⚬ Work effectively both as team member and leader ⚬ Enthusiastic and committed ⚬ Spoken languages: Russian (native), English (fluent), Danish (Prøve i Dansk 3 / level B2) ​ ​ ​ ​ Education 2006–2008: Master’s degree (with distinction) in applied physics. ​ 2002–2006: Bachelor’s degree (with distinction) in applied physics. Under- to postgraduate student at St. Petersburg State Polytechnical University, Faculty of Physics and Technology, Dept. of Cosmic Physics. The thesis “Search for possible space-time variations of the fine-structure constant and isotopic shifts” (a supervisor Prof. ​ M.G. Kozlov). ​ 1992-2002: School education in St. Petersburg, Russia and Belfast, UK (in 1993). Professional Career 2015 – Feb 2021: Software developer in the QuantBio research group at the University of ​ ​ ​ ​ Southern Denmark (SDU), Institute of Physics, Chemistry and Pharmacy (HPC section). I am the principal developer of VIKING, a service providing a web interface for configuring ​ ​ ​ and running scientific computational tasks on supercomputers. I designed the software architecture, developed the system core and coordinated the work of several developers. 2014 – 2015: Lead programmer (Perl) at Internet Projects LLC, russian informational portals subscribe.ru and sendsay.ru (St. Petersburg, Russia). ​ ​ ​ Worked with a team of developers on projects targeted at developing an API for news aggregation and content processing services. This involved integration with various online platforms (Facebook, Twitter, Vkontakte, LiveJournal, Google Analytics), web scraping and designing instruments for user publications at the portals and beyond.
    [Show full text]
  • Node.Js Application Developer's Guide (PDF)
    MarkLogic Server Node.js Application Developer’s Guide 1 MarkLogic 10 June, 2019 Last Revised: 10.0-1, June 2019 Copyright © 2019 MarkLogic Corporation. All rights reserved. MarkLogic Server Table of Contents Table of Contents Node.js Application Developer’s Guide 1.0 Introduction to the Node.js Client API ..........................................................9 1.1 Getting Started ........................................................................................................9 1.2 Required Software ................................................................................................14 1.3 Security Requirements ..........................................................................................15 1.3.1 Basic Security Requirements ....................................................................15 1.3.2 Controlling Document Access ..................................................................16 1.3.3 Evaluating Requests Against a Different Database ..................................16 1.3.4 Evaluating or Invoking Server-Side Code ................................................16 1.4 Terms and Definitions ..........................................................................................17 1.5 Key Concepts and Conventions ............................................................................18 1.5.1 MarkLogic Namespace .............................................................................18 1.5.2 Parameter Passing Conventions ................................................................18
    [Show full text]
  • Node.Js I – Getting Started Chesapeake Node.Js User Group (CNUG)
    Node.js I – Getting Started Chesapeake Node.js User Group (CNUG) https://www.meetup.com/Chesapeake-Region-nodeJS-Developers-Group Agenda ➢ Installing Node.js ✓ Background ✓ Node.js Run-time Architecture ✓ Node.js & npm software installation ✓ JavaScript Code Editors ✓ Installation verification ✓ Node.js Command Line Interface (CLI) ✓ Read-Evaluate-Print-Loop (REPL) Interactive Console ✓ Debugging Mode ✓ JSHint ✓ Documentation Node.js – Background ➢ What is Node.js? ❑ Node.js is a server side (Back-end) JavaScript runtime ❑ Node.js runs “V8” ✓ Google’s high performance JavaScript engine ✓ Same engine used for JavaScript in the Chrome browser ✓ Written in C++ ✓ https://developers.google.com/v8/ ❑ Node.js implements ECMAScript ✓ Specified by the ECMA-262 specification ✓ Node.js support for ECMA-262 standard by version: • https://node.green/ Node.js – Node.js Run-time Architectural Concepts ➢ Node.js is designed for Single Threading ❑ Main Event listeners are single threaded ✓ Events immediately handed off to the thread pool ✓ This makes Node.js perfect for Containers ❑ JS programs are single threaded ✓ Use asynchronous (Non-blocking) calls ❑ Background worker threads for I/O ❑ Underlying Linux kernel is multi-threaded ➢ Event Loop leverages Linux multi-threading ❑ Events queued ❑ Queues processed in Round Robin fashion Node.js – Event Processing Loop Node.js – Downloading Software ➢ Download software from Node.js site: ❑ https://nodejs.org/en/download/ ❑ Supported Platforms ✓ Windows (Installer or Binary) ✓ Mac (Installer or Binary) ✓ Linux
    [Show full text]
  • Developing a Common Web Interface to Various Verification Tools
    Developing a common web interface to various verification tools Bachelor's Thesis Report Roland Meyer [email protected] Supervised by: Malte Schwerhoff Prof. Dr. Peter M¨uller ETH Z¨urich July 27, 2012 Abstract This Bachelor's thesis introduces Tuwin, a system that allows a user to try out a command-line based tool, e.g. a verification tool or a program analyzer, online, without having to install it. This is achieved by giving such tools a common web interface similar to Microsoft Research's rise4fun [1], such that users can execute the tools from their browsers. The system consists of three parts; a central server, a graphical web interface and a number of remote web applications, the tool hosters, where each of them hosts a tool. A user can send input data such as source code to the server which redirects it to the corresponding tool hoster. The tool hoster executes its tool with the user's input and eventually returns its output through the server to the user. All communication between the three components uses standard HTTP/1.1 and messages are JSON [2] or MIME encoded. The server relies on a database for logging and both the server and the tool hoster are configurable through a configuration file. Through this file the tool hoster supports features such as user-selectable command-line parameters, multiple output files of different types, e.g. images or PDF files, or syntax highlighting the input text. Contents 1 Introduction 2 1.1 Motivation . .2 1.2 Goals . .2 1.3 Outline .
    [Show full text]
  • Writing Readable Code
    WRITING READABLE CODE “Any fool can write a code that a computer can understand. Good programmers write code that humans can understand.” - Martin Fowler GENERAL GUIDELINES Writing clean and readable code is not hard, but it is very important toward the maintainability of your program. Readability is achieved by through experience and practiced intuition, but can be guided by key principles including: 1. Good variable names. Every variable should have an identier (name) that directly reflects what it represents. A variable that is describing the number of ducks in a pond might be called ducks or count but it shouldn't be called something like pancakes. Never name your variables as single letters (except for counters in for loops) or anything too abstract. 2. Function naming and responsibility. Make sure your functions also are named well represent what the function does. Every function should also have a single responsibility, something you could describe in a sentence or two. (This is called the SINGLE RESPONSIBILITY PRINCIPLE). 3. Proper formatting. Always maintain correct and consistent indentation, spacing, and location of curly braces, if required by the language. One of the most helpful motivations for clean and consistent formatting is to consider the perspective of the person trying to understand your code, making sure one could painlessly read and interpret your code's purpose through a consistent organization and hierarchal structure. 4. Clear documentation.You should provide clear documentation in all of your web development work, describing functions, key variables or constants, and any particularly complex sections of code. At the same time, your documentation should be client- focused, avoiding implementation details about how your programs are implemented (this latter point is especially relevant when working with function-based programming languages like JavaScript and PHP).
    [Show full text]
  • Minutes of the 42Nd Meeting of TC39, Boston, September 2014
    Ecma/TC39/2014/051 Ecma/GA/2014/118 Minutes of the: 42nd meeting of Ecma TC39 in: Boston, MA, USA on: 23-25 September 2014 1 Opening, welcome and roll call 1.1 Opening of the meeting (Mr. Neumann) Mr. Neumann has welcomed the delegates at Nine Zero Hotel (hosted by Bocoup) in Boston, MA, USA. Companies / organizations in attendance: Mozilla, Google, Microsoft, Intel, eBay, jQuery, Yahoo!, IBM; Facebook, IETF 1.2 Introduction of attendees John Neumann – Ecma International Erik Arvidsson – Google Mark Miller – Google Andreas Rossberg - Google Domenic Denicola – Google Erik Toth – Paypal / eBay Allen Wirfs-Brock – Mozilla Nicholas Matsakis – Mozilla Eric Ferraiuolo – Yahoo! Caridy Patino – Yahoo! Rick Waldron – jQuery Yehuda Katz – jQuery Dave Herman – Mozilla Brendan Eich (invited expert) Jeff Morrison – Facebook Sebastian Markbage – Facebook Brian Terlson – Microsoft Jonathan Turner – Microsoft Peter Jensen – Intel Simon Kaegi – IBM Boris Zbarsky - Mozilla Matt Miller – IETF (liaison) Ecma International Rue du Rhône 114 CH-1204 Geneva T/F: +41 22 849 6000/01 www.ecma-international.org PC 1.3 Host facilities, local logistics On behalf of Bocoup Rick Waldron welcomed the delegates and explained the logistics. 1.4 List of Ecma documents considered 2014/038 Minutes of the 41st meeting of TC39, Redmond, July 2014 2014/039 TC39 RF TG form signed by the Imperial College of science technology and medicine 2014/040 Venue for the 42nd meeting of TC39, Boston, September 2014 (Rev. 1) 2014/041 Agenda for the 42nd meeting of TC39, Boston, September
    [Show full text]
  • Packer: an Opinionated Framework for Using 'Javascript'
    Package ‘packer’ August 14, 2021 Title An Opinionated Framework for Using 'JavaScript' Date 2021-08-14 Version 0.1.1 Description Enforces good practice and provides convenience functions to make work with 'JavaScript' not just easier but also scalable. It is a robust wrapper to 'NPM', 'yarn', and 'webpack' that enables to compartmentalize 'JavaScript' code, leverage 'NPM' and 'yarn' packages, include 'TypeScript', 'React', or 'Vue' in web applications, and much more. License MIT + file LICENSE Encoding UTF-8 RoxygenNote 7.1.1 Imports fs, usethis, jsonlite, htmlwidgets, cli, assertthat, rprojroot, rstudioapi URL https://github.com/JohnCoene/packer, https://packer.john-coene.com BugReports https://github.com/JohnCoene/packer/issues Suggests testthat, covr, golem NeedsCompilation no Author John Coene [aut, cre] (<https://orcid.org/0000-0002-6637-4107>) Maintainer John Coene <[email protected]> Repository CRAN Date/Publication 2021-08-14 12:40:02 UTC R topics documented: add_plugin_clean . .3 add_plugin_eslint . .3 add_plugin_html . .4 add_plugin_prettier . .4 add_plugin_workbox . .4 apply_react . .5 1 2 R topics documented: apply_vue . .5 are_minified . .6 bundle . .6 checks . .7 engine . .7 engine_console . .8 jsdoc . .8 make_library . .9 mockup . .9 npm_console . 10 npm_fix . 10 npm_install . 10 npm_outdated . 11 npm_run . 11 npm_update . 11 put_precommit_hook . 12 put_recommended . 12 put_rprofile_adapt . 12 scaffold_ambiorix . 13 scaffold_extension . 14 scaffold_golem . 15 scaffold_input . 16 scaffold_leprechaun . 17 scaffold_output . 17
    [Show full text]
  • Client-Server Web Apps with Javascript and Java
    Client-Server Web Apps with JavaScript and Java Casimir Saternos Client-Server Web Apps with JavaScript and Java by Casimir Saternos Copyright © 2014 EzGraphs, LLC. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/ institutional sales department: 800-998-9938 or [email protected]. Editors: Simon St. Laurent and Allyson MacDonald Indexer: Judith McConville Production Editor: Kristen Brown Cover Designer: Karen Montgomery Copyeditor: Gillian McGarvey Interior Designer: David Futato Proofreader: Amanda Kersey Illustrator: Rebecca Demarest April 2014: First Edition Revision History for the First Edition: 2014-03-27: First release See http://oreilly.com/catalog/errata.csp?isbn=9781449369330 for release details. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Client-Server Web Apps with JavaScript and Java, the image of a large Indian civet, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.
    [Show full text]