Skip to main content

Home/ javascript/ Group items matching "language" in title, tags, annotations or url

Group items matching
in title, tags, annotations or url

Sort By: Relevance | Date Filter: All | Bookmarks | Topics Simple Middle
Ivan Pavlov

http://www.cs.ucla.edu/~awarth/ometa - 0 views

www.cs.ucla.edu/ometa

followup javascript programming

shared by Ivan Pavlov on 27 Sep 08 - Cached
  • OMeta is a new object-oriented language for pattern matching. It is based on a variant of Parsing Expression Grammars (PEGs) which we have extended to handle arbitrary data types. OMeta's general-purpose pattern matching facilities provide a natural and convenient way for programmers to implement tokenizers, parsers, visitors, and tree transformers, all of which can be extended in interesting ways using familiar object-oriented mechanisms.
Julian Knight

Programming Forums - 0 views

www.programmingforums.org/forum

development imported delicious java javascript perl programming python reference scripting

shared by Julian Knight on 29 Aug 08 - Cached
  • Julian Knight on 29 Aug 08
     
    Lots of languages covered including .net, Perl, Python, JS, Bash, Sed, Awk, PHP, XML, VB, C.., Java
Julian Knight

gotAPI.com :: Reference Lookup Service - 0 views

www.gotapi.com/index.html

css development html imported delicious javascript language perl programming reference sql web

shared by Julian Knight on 29 Aug 08 - Cached
  • Julian Knight on 29 Aug 08
     
    Nice Web2 mashup of a number of reference sources (html, css,JavaScript, DOM, PHP, XML, MySQL, Ruby, etc.)
  • Julian Knight on 29 Aug 08
     
    Nice Web2 mashup of a number of reference sources (html, css, JavaScript, DOM, PHP, XML, MySQL, Ruby, etc.)
Julian Knight

HTML Reference V.2 @ yasininat.com - 0 views

www.yasininat.com/ref

css html javascript php programming reference scripting

shared by Julian Knight on 29 Aug 08 - No Cached
  • Julian Knight on 29 Aug 08
     
    Indexes for main scripting languages
Javier Neira

Why REST ? | /var/log/mind - 0 views

blog.dhananjaynene.com/...why-rest

data integration protocols ftp rpc http analysis

shared by Javier Neira on 09 Jun 09 - Cached
  • ‘ls’ or ‘List Directory’
  • ‘cd’or ‘Change Directory’
  • ‘put’ or ‘Upload’
  • ...26 more annotations...
  • you soon realise that every file and directory is uniquely addressable by its fully qualified path (either absolute or relative) and you can refer to each file and directory by its path. You are also aware that a valid path will uniquely resolve to only one directory or file.
  • the server allows you to retrieve the list of subdirectories and files within your current directory. It always shows you the current state of that directory.
  • following elements
  • A shared understanding of where the files will be uploaded, how they will be uniquely named, their specific file extensions (optionally) and the specific format of the file eg.
  • daemon process on the central office computer (the FTP server) which regularly scans the directory, parses each file as it comes it, does the relevant processing on it, and generates the appropriate result files and places them in the appropriate directories using the shared understanding of the directory structure and the file naming convention to communicate back the results of the processing.
  • RPC allowed you to invoke remote procedures by supporting an ability to pass messages which included the message name and the values for all the parameters necessary to be supplied to the message. Unlike FTP which was meant to do data transfer across a network, RPC was geared to do things remotely.
  • FTP required understanding of very few basic verbs (ls, cd, get, put). Thus the training required to understand FTP semantics was far less than that for RPC. This was partially due to the fact that RPC had a programmatic interface.
  • Moreover each time, new procedures were added or parameters added, these required programmatic changes
  • HTTP protoco
  • Unlike FTP and email, this required the authors to understand a new language, but used a simple markup syntax to keep the learning curve to the minimum
  • get/view/download/save a document
  • Along with RPC, these were essentially different technical manifestations of Service Oriented Architecture (SOA) principles.
  • Many services were usually expected to “do something” though quite often some services would simply return the requested data. Usually but not necessarily the services were identified by using ‘verbs’.
  • allow us to use the web to ‘do something’
  • Resource and media types as the basic units
  • Unique resource identifiers
  • Each resource has often one default manually readable representation
  • Each resource representation optionally includes contextually relevant hyperlinks to other resources
  • REST encourages a uniform interface
  • GET, PUT, POST and DELETE
  • Default Rendering
  • a default HTML rendering capability
  • Aspects such as non maintenance of conversational state, greatly increase the scalability of REST applications even if they do incur a minor cost in efficiency (which can be due to repeated redundant communication of data elements, or additional processing requirements due to preclusion of conversation state).
  • is much easier to understand from a data perspective than an invoice processor API.
  • However the simpler, cleaner and minimalistic abstractions often are far more important than feature richness. A point I would want to make in favour of REST even as I admit that conventional SOA technologies are far more feature rich than REST.
  • REST encourages you to view and model your architecture as a set of resources rather than services.
Javier Neira

JavaScript EE, Part 1: Run JavaScript files on the server side - 0 views

www.ibm.com/...wa-aj-javaee

j2ee javascript jdk 1.6 server client ajax

shared by Javier Neira on 04 Jun 09 - Cached
  • freedom to use the same JavaScript routines on both servers and clients. In addition, the techniques presented throughout this series will allow you to maintain a single code base for both Ajax and non-Ajax clients
  • This double-coding issue can be avoided by using JavaScript combined with Java code on the server side, getting full support of scripting languages through the javax.script API. In addition, the Java SE Development Kit (JDK) 6 already includes Mozilla's Rhino JavaScript engine, which means no setup is required.
  • the toSource() method, which all JavaScript objects must have.
  • ...5 more annotations...
  • engine.eval(scriptReader, vars);
  • sun.org.mozilla.javascript.internal.NativeObject
  • all data exchange between the Java code and the executed script should be done through primitive variables, strings, and Java objects (for example, beans) whose properties and methods can be accessed very easily in the JavaScript code. Simply said, don't try to access native JavaScript objects in your Java code. Use Java objects in the JavaScript code instead.
  • Note that javax.script.Invocable is an optional interface, which some script engines may not implement. The JavaScript engine that comes with JDK 6 does support this interface.
  • you can significantly reduce the execution time by compiling the scripts, using the methods provided by another optional interface named javax.script.Compilable, which is supported by the JavaScript engine of JDK 6.
‹ Previous 21 - 27 of 27
Showing 20▼ items per page