mxGraph Version 4.2.2 – 28. October 2020
Copyright (c) JGraph Ltd 2006-2020
Licensed under Creative Commons Attribution 4.0 International (CC BY 4.0)
mxGraph is a JavaScript component that provides features aimed at applications that display interactive diagrams and graphs. Note by graphs we mean mathematical graphs, not necessarily charts (although some charts are graphs). See later section “What is a Graph?” for more details.
Being a developer library, mxGraph is not designed specifically to provide a ready to use application, although many of the examples are close to being usable applications. mxGraph provides all the commonly required functionality to draw, interact with and associate a context with a diagram. mxGraph comes with a number of examples that help explain how a basic application is put together and showcases individual features of the library.
Developers integrating the library in their application should read the section “Pre-requisites” below. Given that mxGraph is a component part of your application, you must understand how JavaScript web applications are constructed at an architectural level, and how to program both in JavaScript, as well as any server-side languages used.
mxGraph mainly comprises one JavaScript file that contains all of the mxGraph functionality. This is loaded into a HTML web page in a JavaScript section and executes in an HTML container in the browser. This is an incredibly simple architecture that only requires a web server capable of serving html pages and a JavaScript enabled web browser.
The key advantages of this technology are:
The mxGraph components and their relationships
Example applications for a graph visualization library include: process diagrams, workflow and BPM visualization, flowcharts, traffic or water flow, database and WWW visualization, networks and telecommunications displays, mapping applications and GIS, UML diagrams, electronic circuits, VLSI, CAD, financial and social networks, data mining, biochemistry, ecological cycles, entity and cause-effect relationships and organisational charts.
In the typical thin-client environment, mxGraph is split into the client-side JavaScript library and a server-side library in one of the two supported languages, .NET and Java. The JavaScript library is contained as part of a larger web application that is delivered to the browser using a standard web server. All the browser needs is the ability to run JavaScript to be enabled.
In the third part of this manual, you will see an example of an html page that embeds the mxGraph library, as well as a simple application to invoke the library's functionality.
mxGraph uses JavaScript for the client-side functionality on the browser. The JavaScript code in turn uses the underlying vector graphics language on the active browser to render the displayed diagram, currently SVG for all supported browsers. mxGraph also includes the feature to render entirely using html, this limits the range of functionality available, but is suitable for more simple diagrams.
As a developer you are not exposed to browser specific features. As mentioned, the vector graphics language varies by browser, so mxGraph abstracts their features into a common class. Similarly, for event handling and DOMs. Browsers differ in their implementation of these two major browser functionalities, mxGraph exposes a constant API over all browsers and adapts to the inconsistencies behind the scenes.
The JavaScript client of mxGraph is licensed under the Apache 2.0 license. For detailed licensing questions you are always advised to consult a legal professional.
Graph visualization is based on the mathematical theory of networks, graph theory. If you're seeking JavaScript bar charts, pie charts, Gantt charts, have a look at the Google Charts project instead, or similar
A graph consists of vertices, also called nodes, and of edges (the connecting lines between the nodes). Exactly how a graph appears visually is not defined in graph theory. The term cell will be used throughout this manual to describe an element of a graph, either edges, vertices or groups.
A simple Graph
There are additional definitions in graph theory that provide useful background when dealing with graphs, they are listed in the Appendices if of interest to you.
Visualization is the process of creating a useful visual representation of a graph. The scope of visualization functionality is one of mxGraphs' main strength. mxGraph supports a wide range of features to enable the display of cells to only be limited by the skill of the developer and the platform functionality available. Vertices may be shapes, images, vector drawing, animations, virtually any graphical operations available in browsers. You can also use HTML mark-up in both vertices and edges.
Graph Visualization of a transport system. (c) Tourizm Maps
2003, http://www.world-maps.co.uk
Interaction is the way in which an application using mxGraph can alter the graph model through the web application GUI. mxGraph supports dragging and cloning cells, re-sizing and re-shaping, connecting and disconnecting, dragging and dropping from external sources, editing cell labels in-place and more. One of the key benefits of mxGraph is the flexibility of how interaction can be programmed.
Many complex graphical web applications rely on a round-trip to the server in order to form the display, not only the base display but also the interaction events. Although this is often given the title of AJAX functionality, such server reliance is not appropriate for interaction events. Visual feedback taking longer than about 0.2 seconds in an application generally seriously impacts the usability. By placing all of the interaction on the client, mxGraph provides the true feel of an application, rather than seeming like a dumb remote terminal. It also allows the possibility of off-line use.
Selection shading while selecting an area through mouse drag
Graph cells can be drawn anywhere in a simple application, including on top of one another. Certain applications need to present their information in a generally ordered, or specifically ordered structure. This might involve ensuring cells do not overlap and stay at least a certain distance from one another, or that cells appear in specific positions relative to other cells, usually the cells they are connected to by edges. This activity, called the layout application, can be used in a number of ways to assist users in setting out their graph. For non-editable graphs, layout application is the process of applying a layout algorithm to the cells. For interactive graphs, meaning those that can be edited through the UI, layout application might involve only allowing users to make changes to certain cells in certain positions, to re-apply the layout algorithm after each change to the graph, or to apply the layout when editing is complete.
Layout of a workflow using a horizontal hierarchical layout
mxGraph supports a range of tree, force-directed and hierarchical layouts which will fit most layout needs. See the later section on using the layouts for more information.
In a client-server architecture there are two options for how layouts can be run. The Javascript versions provide the ability to run the layouting entirely on the client, while the same layout implementation in Java on the server-side enables the option to offload some processing to the server, if required.
Analysis of graphs involves the application of algorithms determining certain details about the graph structure, for example, determining all routes or the shortest path between two cells. There are more complex graph analysis algorithms, these being often applied in domain specific tasks. Techniques such as clustering, decomposition, and optimization tend to be targeted at certain fields of science and have not been implemented in the core mxGraph packages at the current time of writing.
Shortest Path Analysis
To benefit fully from this manual you will need to have a reasonable understanding of web applications and of the server technology you wish to deploy using. Deployment examples are available for each of the server technologies supported, some familiarity with that server technology is obviously required.
Basic XML knowledge is useful for changing the editor configuration files that describe the visual and behavioural aspects of the editor. You will need to understand and implement Javascript coding and be familiar with object orientated programming principles and modern software design.
You do not need knowledge of the underlying vector graphics language that the browser uses, such as SVG or HTML canvas. mxGraph abstracts the description of the visual component into one API.
mxGraph is available from the GitHub project. Released versions are tagged "va.b.c", where a, b and c are version number parts following semantic versioning.
Each formal release is also available as .zip or .tar.gz on the mxGraph releases page.
Once unzipped you will be presented with a number of files and directories in the installation root.
|
/doc |
Documentation root, includes this user manual |
|
/dotnet |
.NET server-side classes |
|
/java |
Java server-side classes |
|
/javascript |
JavaScript client functionality. |
|
/javascript/examples |
HTML examples demonstrating the use of mxGraph |
|
ChangeLog |
Details of the changes between releases |
|
index.html |
Basic introduction to the library |
|
license.txt |
The licensing terms under which you must use the library |
Table: Project Directory Structure
mxGraph is also available via the npm package manager. To use mxGraph as
a depedency, use npm install
:
npm install mxgraph --save
The module can be loaded using require()
. This returns a
factory function that accepts an object of options. Options such as
mxBasePath
must be provided to the factory function, rather
than specified as global variables.
var mxgraph = require("mxgraph")({ mxImageBasePath: "./src/images", mxBasePath: "./src" })
The factory function returns a 'namespace object' that provides access to
all objects of the mxGraph package. For example, the mxEvent
object is available at mxgraph.mxEvent
.
var mxEvent = mxgraph.mxEvent; mxEvent.disableContextMenu(container);
Web applications, specifically the use of JavaScript to attempt to emulate desktop application-like behaviour in web browsers, is still a relatively new field of software engineering. There are three main issues with JavaScript that are perceived to be a barrier to producing high quality applications, performance, lack of native functionality available in desktop applications and inconsistent APIs between browsers.
There has been considerable effort toward developing framework libraries to solve two of the problems, the functionality and API issues. The requirements of many of these libraries is driven by both improving web site design and usability, as well as to assist production of what we generally refer to as application features (menus, windows, dialogs, persistence, event handling, etc). They also provide certain base functionalities missing in JavaScript that desktop application developers take for granted, such as basic maths and collections functionality.
Many of these JavaScript frameworks have IDE support for development nowadays and all of the major browsers now contain JavaScript debuggers, either natively or as a plug-in. There is no compilation phase with JavaScript (it is an interpreted language) so basic typographical errors are often only caught at runtime, unless you obtain a syntax checking tool in your IDE. So although there is not one complete package for your JavaScript development needs, there are a number of vendors providing the individual components you need to produce JavaScript applications effectively.
Rather than list and compare every JavaScript framework, please see the wikipedia entries for web application frameworks and the comparison of JavaScript. The comparison should not be considered authoritative, more so it illustrates the types of features provided, such as event handling, animation, widgets, AJAX request support etc.
Be aware that many frameworks add implicit behaviours to make JavaScript appear more like an OO language and to increase the base functionality of the language. During the writing of the layout portion of mxGraph, it was found that this implicit behaviour broke an example in a very hard to debug manner. Be aware that this may cause problems and if you select a framework ensure you understand which implicit behaviours it introduces.
When selecting a framework and/or libraries think about which frameworks tie you into certain functional behaviour and look for libraries that provide features such as animation as distinct, independent blocks, that you can use without being tied into the overall design.
This area is often misunderstood, put simply, there is no integration required. Web applications generally comprise one or more div elements into which the HTML wrapping the JavaScript of the application is placed. If you create a div as a container for an mxGraph, that area is a stand-alone display for the mxGraph application. It can communicate itself with any back-end server, but there is no interdependence between that div and the rest of the page, other than the area each take up. This includes event handling, mxGraph can handle the events for its container, even if the rest of the web page used a completely different event model. As long as neither mxGraph nor the other libraries and frameworks on the page introduce implicit behaviours that break one part of the page, the issue of client integration is not something that needs analysis.
Integration of the mxGraph back-end functionality, that which sits at the server-side is the subject of a later chapter.
In JavaScript, there are various ways of mapping the Object Oriented paradigm to language constructs. mxGraph uses a particular scheme throughout the project, with the following implicit rules:
There are two types of “classes” in mxGraph; classes and singletons (where only one instance of the class exists). Singletons are mapped to global objects where the variable name is the same as the class name. For example, mxConstants is an object with all the constants defined as object fields. Normal classes are mapped to a constructor function and a prototype which defines the instance fields and methods. For example, mxEditor is a function and mxEditor.prototype is the prototype for the object that the mxEditor function creates. The mx prefix is a convention that is used for all classes in the mxGraph package to avoid conflicts with other objects in the global namespace.
For subclassing, the superclass must provide a constructor that is either parameterless or handles an invocation with no arguments. Furthermore, the special constructor field must be redefined after extending the prototype. For example, the superclass of mxEditor is mxEventSource. This is represented in JavaScript by first “inheriting” all fields and methods from the superclass by assigning the prototype to an instance of the superclass, eg.
mxEditor.prototype = new mxEventSource()
and redefining the constructor field using:
mxEditor.prototype.constructor = mxEditor
The latter rule is applied so that the type of an object can be retrieved via the name of it’s constructor using mxUtils.getFunctionName(obj.constructor).
For subclassing in mxGraph, the same mechanism should be applied. For example, for subclassing the mxGraph class, first a constructor must be defined for the new class. The constructor calls the super constructor with any arguments that it may have using the call function on the mxGraph function object, passing along explicitly each argument:
function MyGraph(container) { mxGraph.call(this, container); }
The prototype of MyGraph inherits from mxGraph as follows. As usual, the constructor is redefined after extending the superclass:
MyGraph.prototype = new mxGraph(); MyGraph.prototype.constructor = MyGraph;
You may want to define the codec associated for the class after the above code (see I/O section of manual). This code will be executed at class loading time and makes sure the same codec is used to encode instances of mxGraph and MyGraph.
var codec = mxCodecRegistry.getCodec(mxGraph); codec.template = new MyGraph(); mxCodecRegistry.register(codec);
In the prototype for MyGraph, functions of mxGraph can be extended as follows.
MyGraph.prototype.isSelectable = function(cell) { var selectable = mxGraph.prototype.isSelectable.apply(this, arguments); var geo = this.model.getGeometry(cell); return selectable &&(geo == null || !geo.relative); }
The supercall in the first line is optional. It is done using the apply function on the isSelectable function object of the mxGraph prototype, using the special this and arguments variables as parameters. Calls to the superclass function are only possible if the function is not replaced in the superclass as follows, which is another way of “subclassing” in JavaScript.
mxGraph.prototype.isSelectable = function(cell) { var geo = this.model.getGeometry(cell); return selectable && (geo == null || !geo.relative); }
The above scheme is useful if a function definition needs to be replaced completely.
In order to add new functions and fields to the subclass, the following code is used. The example below adds a new function to return the XML representation of the graph model:
MyGraph.prototype.getXml = function() { var enc = new mxCodec(); return enc.encode(this.getModel()); }
Likewise, a new field is declared and defined as follows:
MyGraph.prototype.myField = ‘Hello, World!’;
Note that the value assigned to myField is created only once, that is, all instances of MyGraph share the same value. If you require instance-specific values, then the field must be defined in the constructor instead. For example:
function MyGraph(container) { mxGraph.call(this, container); this.myField = []; }
Finally, a new instance of MyGraph is created using the following code, where container is a DOM node that acts as a container for the graph view:
var graph = new MyGraph(container);
By default, when you deliver JavaScript to a browser client, you deliver the entire source to that JavaScript. That JavaScript is then interpreted and run on the browser. It is not possible to encrypt the JavaScript to any extent on the client at the point it is run, since the JavaScript source must be understood by the JavaScript interpretor and interpreted languages do not have a binary intermediate form.
It would be possible to encrypt the JavaScript in transmission and have it decrypted and run on the client, but the client would still be able to access the source after decryption.
We do not obfuscate because the method names form a public API and I/O would need to understand the obfuscation at both communication ends.
The concept of namespaces does not exist in standised JavaScript, so take
great care when creating new class names. In mxGraph, all of the classes
begin with the prefix “mx-”, to avoid clashes or overriding
prototypes unintentionally.
Hello World in mxGraph consists of a simple client-side example that displays two connected vertices with the labels “Hello” and “World!”. The example demonstrates the following things:
The source code for the example, helloworld.html, can be found below and in the examples directory of both the evaluation and full versions of mxGraph. The HTML source contains two main sections, the head and the body. These contain the following main elements that you can consider a template for building a basic mxGraph application:
Note that the overflow:hidden style should always be used if you want no scrollbars to appear.
The mxGraph HelloWorld example
<html> <head> <title>Hello, World! example for mxGraph</title> <!-- Sets the basepath for the library if not in same directory --> <script type="text/javascript"> mxBasePath = '../src'; </script> <!-- Loads and initializes the library --> <script type="text/javascript" src="../src/js/mxClient.js"></script> <!-- Example code --> <script type="text/javascript"> // Program starts here. Creates a sample graph in the // DOM node with the specified ID. This function is invoked // from the onLoad event handler of the document (see below). function main(container) { // Checks if the browser is supported if (!mxClient.isBrowserSupported()) { mxUtils.error('Browser is not supported!', 200, false); } else { // Creates the graph inside the given container var graph = new mxGraph(container); // Enables rubberband selection new mxRubberband(graph); // Gets the default parent for inserting new cells. This // is normally the first child of the root (ie. layer 0). var parent = graph.getDefaultParent(); // Adds cells to the model in a single step graph.getModel().beginUpdate(); try { var v1 = graph.insertVertex(parent, null, 'Hello,', 20, 20, 80, 30); var v2 = graph.insertVertex(parent, null, 'World!', 200, 150, 80, 30); var e1 = graph.insertEdge(parent, null, '', v1, v2); } finally { // Updates the display graph.getModel().endUpdate(); } } }; </script> </head> <!-- Page passes the container for the graph to the program --> <body onload="main(document.getElementById('graphContainer'))"> <!-- Creates a container for the graph with a grid wallpaper --> <div id="graphContainer" style="overflow:hidden;width:321px;height:241px;background:url('editors/images/grid.gif')"> </div> </body> </html>
Important concepts to note in this exercise are:
There are two versions of the mxClient.js file, one for production use and a second for development/debugging use. javascript/src/js/mxClient.js is the production version and javascript/debug/js/mxClient.js is for development. The first version has all linefeeds stripped to ensure the file is the minimal size possible. This has the side-effect of breaking most JavaScript debuggers. During development you are advised to use the debug version, which has the linefeeds in, enabling debugging in the supported browsers.
Both mxClient.js files are the entire JavaScript source to mxGraph, with all of the whitespace and comments removed to reduce file size. Whilst debugging, it is easier to use the individual source files if you need to debug into the mxGraph library itself. The source code version of mxGraph contains the full source in the source.zip file in the javascript/devel directory. Unzipping this into the mxBasePath and removing the load of the complete mxClient.js file enables easier debugging of mxGraph. Note that the mxClient.js file in the source zip is a bootstrap file that loads all the other JavaScript source code.
The download speed of the client source can be further improved by compressing the code. All modern browsers support receiving and uncompressing transmissions compressed at the server end and all good web servers support detection of those browser that do not support it and send the uncompressed version as a fallback.
For example, on the Apache web server there is a mod_deflate module, details of its use can be found from a standard search. The jgraph.com server uses this module and there have been no reports of issues in any supported browser.
The use of compression reduces the mxClient.js file size down from about 600KB to around 130KB. The difference is not noticed by the user on most modern networks, but there might be situations where the smaller version would be preferable.
The mxGraph model is the core model that describes the structure of the graph, the class is called mxGraphModel and is found within the model package. Additions, changes and removals to and from the graph structure take place through the graph model API. The model also provides methods to determine the structure of the graph, as well as offering methods to set visual states such as visibility, grouping and style.
However, although the transactions to the model are stored on the model, mxGraph is designed in such a way that the main public API is through the mxGraph class. The concept of “add this cell to the graph” is a more natural description of the action than “add this cell to the model of the graph”. Where it is intuitive, functions available on the model and cells are duplicated on the graph and those methods on the graph class are considered the main public API. Throughout the rest of this manual these key API methods are given a pink background:
anExampleCoreAPIMethod()
So, though many of the main API calls are through the mxGraph class, keep in mind that mxGraphModel is the underlying object that stores the data structure of your graph.
mxGraph uses a transactional system for making changes to the model. In the HelloWorld example we saw this code:
// Adds cells to the model in a single step graph.getModel().beginUpdate(); try { var v1 = graph.insertVertex(parent, null, 'Hello,', 20, 20, 80, 30); var v2 = graph.insertVertex(parent, null, 'World!', 200, 150, 80, 30); var e1 = graph.insertEdge(parent, null, '', v1, v2); } finally { // Updates the display graph.getModel().endUpdate(); }
to perform the insertion of the 2 vertices and 1 edge. For each change to the model you make a call to beginUpdate(), make the appropriate calls to change the model, then call endUpdate() to finalize the changes and have the change event notifications sent out.
Key API Methods:
Note – Technically you do not have to surround your changes with the begin and end update calls. Changes made outside of this update scope take immediate effect and send out the notifications immediately. In fact, changes within the update scope enact on the model straight away, the update scope is there to control the timing and concatenation of event notifications. Unless the update wrapping causes code aesthetic issues, it is worth using it by habit to avoid possible problems with event and undo granularity.
Note the way in which the model changes are wrapped in a try block and the endUpdate() in a finally block. This ensures the update is completed, even if there is an error in the model changes. You should use this pattern wherever you perform model changes for ease of debugging.
Ignore the reference to the parent cell for now, that will be explained later in this chapter.
The sub-transaction in the blue block above refers to the fact that transactions can be nested. That is, there is a counter in the model that increments for every beginUpdate call and decrements for every endUpdate call. After increasing to at least 1, when this count reaches 0 again, the model transaction is considered complete and the event notifications of the model change are fired.
This means that every sub-contained section of code can (and should) be surrounded by the begin/end combination. This provide the ability in mxGraph to create separate transactions that be used as “library transactions”, the ability to create compound changes and for one set of events to be fired for all the changes and only one undo created. Automatic layouting is a good example of where the functionality is required.
In automatic layouting, the user makes changes to the graph, usually through the user interface, and the application automatically positions the result according to some rules. The automatic positioning, the layouting, is a self-contained algorithm between begin/end update calls that has no knowledge of the specifics of the change. Because all changes within the begin/end update are made directly to the graph model, the layout can act upon the state of the model as the change is in progress.
It is important to distinguish between functionality that acts on the graph model as part of a compound change and functionality that reacts to atomic graph change events. In the first case, such as for automatic layouting, the functionality takes the model as-is and acts upon it. This method should only be used for parts of compound model changes. All other parts of the application should only react to model change events.
Model change events are fired when the last endUpdate call reduces the counter back down to 0 and indicate that at least one atomic graph change has occurred. The change event contains complete information as to what has altered (see later section on Events for more details).
Below is a list of the methods that alter the graph model and should be placed, directly or indirectly, with the scope of an update:
Initially, we will just concern ourselves with the add and remove, as well as the geometry and style editing methods. Note that these are not core API methods, as usual these methods are on the mxGraph class, where appropriate, and they perform the update encapsulation for you.
Design Background - Some people are confused by the presence of visual information being stored by the model. These attributes comprise cell positioning, visibility and collapsed state. The model stores the default state of these attributes, providing a common place to set them on a per-cell basis, whereas, views can override the values on a per-view basis. The model is simply the first common place in the architecture where these attributes can be set on a global basis. Remember, this is a graph visualization library, the visualization part is the core functionality.
The three graph cells created in the HelloWorld
application are two vertices and one edge connecting the vertices. If
you are not familiar with basic graph theory and its terminology, please
see the wikipedia
entry.
You can add vertices and edges using the add() method on the model. However, for the purposes of general usage of this library, learn that mxGraph.insertVertex() and mxGraph.insertEdge() are the core public API for adding cells. The function of the model requires that the cell to be added is already created, whereas the mxGraph.insertVertex() creates the cell for you.
Core API functions:
mxGraph.insertVertex()
will create an mxCell object
and return it from the method used. The parameters of the function are:
graph.getDefaultParent();
as your default parent, as used in the HelloWorld example.With the edge addition method, the identically named parameters perform the same function as in the vertex addition method. The source and target parameters define the vertices to which the edge is connected. Note that the source and target vertices should already have been inserted into the model.
mxCell is the cell object for both vertices and edges. mxCell duplicates many of the functions available in the model. The key difference in usage is that using the model methods creates the appropriate event notifications and undo, using the cell makes the change but there is no record of the change. This can be useful for temporary visual effects such as animations or changes on a mouse over, for example. As a general rule though, use the model editing API unless you encounter a specific problem with this mechanism.
When creating a new cell, three things are required in the constructor, a value (user object), a geometry and a style. We will now explore these 3 concepts before returning to the cell.
The concept of styles and stylesheets in conceptually similar to CSS stylesheets, though note that CSS are actually used in mxGraph, but only to affect global styles in the DOM of the HTML page. Open up the util.mxConstants.js file in your editor and search for the first match on “STYLE_”. If you scroll down you will see a large number of strings defined for all the various styles available with this prefix. Some of styles apply to vertices, some to edges and some to both. As you can see, these define visual attributes on the element they act upon.
The mxStylesheet holds one object, styles, which is a hashtable mapping style names to an array of styles:
Style arrays within the styles collection
In the above image the blue box represents the styles hashtable in mxStyleSheet. The string 'defaultVertex' is the key to an array of string/value pairs, which are the actual styles. Note that mxGraph creates two default styles, one for vertices and one for edges. If you look back to the helloworld example, no style was passed into the optional style parameter of insertVertex or insertEdge. In this case the default style would be used for those cells.
If you wanted to specify a style other than the default for a cell, you must pass that new style either to the cell when it is created (mxGraph's insertVertex and insertEdge both have an optional parameter for this) or pass that style to the cell using model.setStyle().
The style that you pass has the form stylename. ,note that the stylenames and key/value pairs may be in any order. Below are examples to demonstrate this concept, adapting the insertVertex call we saw in helloworld:
A new style called 'ROUNDED' has been created, to apply this to a vertex:
var v1 = graph.insertVertex(parent, null, 'Hello', 20, 20, 80, 30, 'ROUNDED');
To create a new vertex with the ROUNDED style, overriding the stroke and fill colors:
var v1 = graph.insertVertex(parent, null, 'Hello', 20, 20, 80, 30, 'ROUNDED;strokeColor=red;fillColor=green');
To create a new vertex with no global style, but with local stroke and fill colors:
var v1 = graph.insertVertex(parent, null, 'Hello', 20, 20, 80, 30, ';strokeColor=red;fillColor=green');
To create a vertex that uses the defaultVertex style, but a local value of the fill color:
var v1 = graph.insertVertex(parent, null, 'Hello', 20, 20, 80, 30, 'defaultVertex;fillColor=blue');
Note that default style must be explicitly named in this case, missing the style out sets no global style on the cell when the semi-colon starts the string. If the string starts with no semi-colon, the default style is used.
Again, the mxGraph class provides utility functions that form the core API for accessing and changing the styles of cells:
Core API functions:
To create the ROUNDED global style described above, you can follow this template to create a style and register it with mxStyleSheet:
var style = new Object(); style[mxConstants.STYLE_SHAPE] = mxConstants.SHAPE_RECTANGLE; style[mxConstants.STYLE_OPACITY] = 50; style[mxConstants.STYLE_FONTCOLOR]= '#774400'; graph.getStylesheet().putCellStyle('ROUNDED',style);
In the helloworld example we saw the position and size of the vertices passed into the insertVertex function. The coordinate system in JavaScript is x is positive to the right and y is positive downwards, and in terms of the graph, the positioning is absolute to the container within which the mxGraph is placed.
The reason for a separate mxGeometry class, as opposed to simply having the mxRectangle class store this information, is that the edges also have geometry information.
The width and height values are ignored for edges and the x and y values relate to the positioning of the edge label. In addition, edges have the concept of control points. These are intermediate points along the edge that the edge is drawn as passing through. The use of control points is sometimes referred to as edge routing.
An edge routed by 2 control points
There are two more important additional concepts in geometry, relative positioning and offsets
By default, the x and y position of a vertex is the offset of the top left point of the bounding rectangle of the parent to the top left point of the bounding rectangle of the cell itself. The concept of parents and groups is discussed later in this chapter, but without going into too much detail, if a cell does not have cell parent, the graph container is its parent for positioning purposes.
Non-relative vertex positioning
For an edge, in non-relative mode, which is the default mode, the edge label position is the absolute offset from the graph origin.
Non-relative edge label positioning
For vertices in relative mode, (x,y) is the proportion along the parent cell's (width, height) where the cell's origin lies. (0,0) is the same origin as the parent, (1,1) places the origin at the bottom right corner of the parent. The same relative positioning extends below 0 and above 1 for both dimensions. This positioning is useful for keeping child cells fixed relative to the overall parent cell size.
Relative vertex positions
Lastly, edge labels in relative mode are palced based on the positioning from the center of the edge. The x-coordinate is the relative distance from the source end of the edge, at -1, to the target end of the edge, at 1. The y co-ordinate is the pixel offset orthogonal from the edge. The diagram below shows the values of x,y for various edge labels in relative mode. Note that for a straight edge, the calculations are simple. For edges with multiple control points, the edge has to be traced along its segments (a segment being the line between end points and/or control points) to find the correct distance along the edge. The y value is the orthogonal offset from that segment.
Switching relative positioning on for edge labels is a common preference for applications. Navigate to the mxGraph.insertEdge() function in mxGraph, you will see this calls createEdge(). In createEdge() the geometry is set relative for every edge created using this prototype. This is partly the reason for the amount of helper functions in mxGraph, they enable easy changing of the default behaviour. You should try to use the mxGraph class API as much as possible to provide this benefit in your applications.
The offset field in mxGeometry is an absolute x,y offset applied to the cell label. In the case of edge labels, the offset is always applied after the edge label has been calculated according to the relative flag in the above section.
Core API functions:
The User object is what gives mxGraph diagrams a context, it stores the business logic associated with a visual cell. In the HelloWorld example the user object has just been a string, in this case it simply represents the label that will be displayed for that cell. In more complex applications, these user objects will be objects instead. Some attribute of that object will generally be the label that the visual cell will display, the rest of the object describes logic relating to the application domain.
Using the example of a simple workflow or process application, say we have the graph below (this example is available online, select the Swimlanes example from the tasks window):
A simple workflow
Typically, this workflow will exist on some application server and/or database. The browser user connects to that server, or some front-end server linked to the application server and the user's web application requests the “order” workflow. The server obtains the data of that workflow and transmits it to the client.
mxGraph supports the process of populating the model on the server-side and transmitting to the client, and back again. See the later chapter on “I/O and Server Communication”.
The data transmitted will be both the visual model (the diagram) as well as the business logic (mostly contained in the user objects). The client will initially show the diagram above. If the user has permission to edit this workflow they will normally be able to do two things, 1) edit the diagram, add and remove vertices, as well as changing the connections, and 2) edit the user objects of the cells (vertices and/or edges).
In the online demo, if you right click and select properties of the “Check Inventory” diamond you will see this dialog:
The properties of a vertex
These properties show the geometry, label, ID etc, but a dialog could just as easily show the user object of the cell. There might be a reference to some process on the workflow engine as to how the inventory is actually checked. This might be an application specific mechanism for both the server and client to assign some identification to remote method calls. Another value might be the type of object that process returned, maybe a boolean or an integer to indicate stock level in this case. Given that return type, it is possible to enforce constraints with the diagram and provide visual alerts of if, say, the outgoing edges decision check does not correspond to the return type of the vertex.
Next, as an example, the user objects of the outgoing edges might contain a label and a boolean state. Again, the mxGraph-based editor might provide the means to alter the boolean value. On the server, when executing the process, it might follow the edges that correspond to the boolean value returned by the decision node.
Keep in mind that the above example is very domain specific, it is there to explain how the user object maps to the business logic of the application. It visualizes how mxGraph creates what we term a contextual graph. The context is formed by the connections between vertices and the business logic stored within the user objects. A typical application receives the visual and business logic from a sever, may allow editing of both, then transmits both back to the server for persistence and/or execution.
As described previously, mxGraph is the primary API for using this library and the same concept applies to cells. One basic state of the cell not exposed on the graph is whether a cell is a vertex or an edge, this call be performed on the cell or on the model.
There are two boolean flags on mxCell, vertex and edge, and the helper methods set one of these to true when the cell is created. isVertex(), isEdge() on mxIGraphModel are what the model uses to determine a cell's type, there are not separate objects for either type. Technically, it is possible to switch the type of a cell at runtime, but take care to invalidate the cell state (see later section) after changing the type. Also, be aware that the geometry object variable means different things to vertices and edges. Generally, it is not recommended to change a cell type at runtime.
Grouping, within mxGraph, is the concept of logically associating cells with one another. This is commonly referred to as the concept of sub-graphs in many graph toolkits. Grouping involves one or more vertices or edges becoming children of a parent vertex or edge (usually a vertex) in the graph model data structure. Grouping allows mxGraph to provide a number of useful features:
In grouping, cells are assigned a parent cell. In the simplest case, all cells have the default parent as their parent. The default parent is an invisible cell with the same bounds as the graph. This is the cell returned by graph.getDefaultParent() in the helloworld example. The x,y position of a vertex is its position relative to its parent, so in the case of default grouping (all cells sharing the default parent) the cell positioning is also the absolute co-ordinates on the graph component. In the case all cells being added to the default root, the group structure logically looks like, in the case of the helloworld example, the diagram below.
Note the addition of the Layer 0 cell, this is the default indirection in the group structure that allows layer changes with the requirement of additional cells. We include it below for correctness, but in later group diagrams it will be omitted.
The group structure of the helloworld example
Also, note that the position of the edge label (x,y in geometry) is relative to the parent cell.
If we go back to the simple workflow example in the User Objects section, we can see what grouping might look like visually. In the example the group cells represent people and the child vertices represent tasks assigned to those people. In this example the logical group structure looks like this:
The logical group structure of the workflow example
The workflow action vertices are the yellow children and the swimlane group vertices are marked blue.
Inserting cells into the group structure is achieved using the parent parameter of the insertVertex and insertEdge functions on the mxGraph class. These functions set the parent cell on the child accordingly and, importantly, informs the parent cell of its new child.
Altering the group structure is performed via the mxGraph.groupCells() and mxGraph.ungroupCells() functions.
Core API functions:
There are two primary reasons to control the number of cells displayed at any one time. The first is performance, drawing more and more cells will reach performance usability limits at some point on any platform. The second reason is ease of use, a human can only comprehend a certain amount of information. All of the concepts associated with grouping, listed above, can be used to reduce the complexity of information on the screen for the user.
Folding is the collective term we use for expanding and collapsing groups. We say a cell is folded by making it's child vertices invisible. There are a number of functions relating to this feature:
Core API function:
Folding related functions:
mxGraph.isCellFoldable(cell, collapse) – By default true for cells with children.
mxGraph.isCellCollapsed(cell) – Returns the folded state of the cell
When a group cell is collapsed, three things occur by default:
Expanded swimlane
Collapsed Swimlane
The above two images demonstrate these three concepts. In its expanded state the upper group cell displays a small box in the top left hand corner with a “-” character inside. This indicates that clicking on this box collapses the group cell. Doing this we get the bottom image where the group cell takes on its collapsed size. Child vertices and edge that do not leave the group cell are made invisible. Finally, edges that exit the group cell are promoted to appear to be connected to the collapsed group cell. Clicking on the “+” character that now appears within the box expands the group cell and brings it back to its original state of the top image.
Using the mxGraph.foldCells() function, you can achieve the same result programmatically as clicking on the expand/collapse symbols. One common usage of this is when the application zooms out a specific amount, clusters of cells are grouped and the grouped cell collapsed (very often without the “-” box since the application is controlling the folding). This way fewer, larger cells are visible to the user, each one representing their children cells logically. You might then provide a mechanism to zoom into a group, which expands it in the process. You might also provide drill-down/step-up, explained next.
Sometimes, as an alternative to expand/collapse, or possibly in combination with it, your graph will be composed of a number of graphs, nested into a hierarchy. Below we see a simple example:
An example top level workflow
This simple workflow consists of three high level steps. Obviously, the individual steps contain a number of sub-steps and we will look at a sub-graph of the Solve Bug cell.
Under the Solve Bug vertex we have created a number of children to represent the process of solving a bug in more detail, in this case the process of solving a bug on the Starship Enterprise.
In this example, which uses the GraphEditor example, the menu option shown selected in the above image invokes mxGraph.enterGroup(cell), which is one of the pair of core API functions for sub-graphs.
Core API functions:
The root cell of the graph has been, up to now, the default parent vertex to all first-level cells. Using these functions you can make any group cell in the group structure the root cell, so that the children of that parent appear in the display as the complete graph.
Result of drilling down into the Solve Bug vertex
The same graph expanded using folding instead looks like:
Exiting the group using the shape->exit group option, which invokes mxGraph.exitGroup, brings you back to the original 3 vertex top level graph.
In mxGraph, like many graphical applications, there is the concept of z-order. That is, the order of objects as you look into the screen direction. Objects can be behind or in front of other objects and if they overlap and are opaque then the back-most object will be partially or complete obscured. Look back to the graph structure of HelloWorld illustration above. Children cells are stored under parents in a deterministic order (by default the order in which you add them).
If we move the cells in the HelloWorld example we see the following result:
Overlapped vertices
It can be seen that the World vertex is in front of the Hello vertex. This is because the World vertex has a higher child index than the Hello vertex, at positions 1 and 0 respectively in the ordered collection that holds the children of the root cell.
To change order we use mxGraph.orderCells.
Core API function:
A sibling cell in mxGraph is any cell that shares the same parent. So by invoking this on the Hello vertex it would then overlap the World Vertex.
Ordering and grouping can be extended to form logically layered groups. The cells are drawn via a depth-first search. Take the HelloWorld example again and imagine that both the Hello and World vertices have some hierarchy of children underneath them. The Hello vertex and all of its children will be drawn before the World vertex or any of its children. If Hello and World were invisible group cells you then have two hierarchies of cells, one being drawn entirely before the other. You can also switch the order of the hierarchies by simply switching the order of the invisible group cells.
The concept of layering is demonstrated in the layers.html example. Here buttons are used to set the visibility of group layer cells. This example ties very closely into the concept of filtering.
In filtering cells with some particular attribute are displayed. One option to provide filtering functionality is to check some state before rendering the cells. Another method, if the filtering conditions are simple and known in advance, is to assign filterable cells by groups. Making the groups visible and invisible performs this filtering operation.


The priority of a scene defines its place in the final project.
The scene with priority 0 will be the first, priority 1 will be the second and so on.
Every scene needs a unique priority.
You have to refresh the page when you alter a scene with Manim.
Otherwise the displayed data may be outdated.
Scene
Sections
{% for scene in scenes %}
#{{ scene.id }} {{ scene.name }}
in: {{ scene.get_rel_dir_path() }}
Last modified on: {{ scene.get_last_modified() }}


Check Commands
functions to handle user commands: 'new-list' or 'add' command with data
- Source:
Methods
(inner) formatString formats a list(items, listType) → {string}
Parameters:
| Name | Type | Description |
|---|---|---|
items |
string | |
listType |
string |
- Source:
Returns:
a string that formatted to print as a list
- Type
- string
(inner) handleCommand checks the user command for a MagPi match(arr)
Parameters:
| Name | Type | Description |
|---|---|---|
arr |
array |
- Source:
Fires:
- event:green-flash
- event:blue-off
- event:send-list


I grew up skiing. It is probably my favorite past time. I have been doing it for sense I was 4. I stated off at a small mountain in New hampshire and worked my way up to the big Sugerloaf. Here are my favorite ski mountains.
5.Cranmore
4.Cannon
3.Sunday River
2. Attatash
1. Sugarloaf
Back to Home Click here


class BoxConstraintsLinQuadTransformation(BoxConstraintsTransformationBase):
implement a bijective, monotonous transformation between [lb - al, ub + au] and [lb, ub].
Generally speaking, this transformation aims to resemble sin to be a continuous differentiable (ie. C^1) transformation over R into a bounded interval; then, it also aims to improve over sin in the following two ways: (i) resemble the identity over an interval as large possible while keeping the second derivative in reasonable limits, and (ii) numerical stability in "pathological" corner cases of the boundary limit values.
The transformation is the identity (and therefore linear) in [lb + al, ub - au] (typically about 90% of the interval) and quadratic in [lb - 3*al, lb + al] and in [ub - au, ub + 3*au]. The transformation is periodically expanded beyond the limits (somewhat resembling the shape sin(x-pi/2)) with a period of 2 * (ub - lb + al + au).
Details
Partly due to numerical considerations depend the values al and au on abs(lb) and abs(ub) which makes the transformation non-translation invariant. In particular, the linear proportion decreases to zero when ub-lb becomes small. In contrast to sin(.), the transformation is also robust to "arbitrary" large values for boundaries, e.g. a lower bound of -1e99 or upper bound of np.Inf or bound None.
Examples
Example to use with cma:
>>> import warnings >>> import cma >>> from cma.transformations import BoxConstraintsLinQuadTransformation >>> # only the first variable has an upper bound >>> tf = BoxConstraintsLinQuadTransformation([[1,2], [1,None]]) # second==last pair is re-cycled >>> with warnings.catch_warnings(record=True) as warns: ... x, es = cma.fmin2(cma.ff.elli, 9 * [2], 1, ... {'transformation': [tf.transform, tf.inverse], ... 'verb_disp':0, 'tolflatfitness': 1e9, 'verbose': -2}) >>> not warns or str(warns[0].message).startswith(('in class GenoPheno: user defi', ... 'flat fitness')) True
or:
>>> es = cma.CMAEvolutionStrategy(4 * [2], 1, {'verbose':0, 'verb_log':0}) # doctest: +ELLIPSIS (4_w,8)-aCMA-ES (mu_w=... >>> with warnings.catch_warnings(record=True) as warns: # flat fitness warning, not necessary anymore ... while not es.stop(): ... X = es.ask() ... f = [cma.ff.elli(tf(x)) for x in X] # tf(x)==tf.transform(x) ... es.tell(X, f) >>> assert 'tolflatfitness' in es.stop(), str(es.stop())
Example of the internal workings:
>>> from cma.transformations import BoxConstraintsLinQuadTransformation >>> tf = BoxConstraintsLinQuadTransformation([[1,2], [1,11], [1,11]]) >>> tf.bounds [[1, 2], [1, 11], [1, 11]] >>> tf([1.5, 1.5, 1.5]) [1.5, 1.5, 1.5] >>> list(np.round(tf([1.52, -2.2, -0.2, 2, 4, 10.4]), 9)) [1.52, 4.0, 2.0, 2.0, 4.0, 10.4] >>> res = np.round(tf._au, 2) >>> assert list(res[:4]) == [ 0.15, 0.6, 0.6, 0.6] >>> res = [round(x, 2) for x in tf.shift_or_mirror_into_invertible_domain([1.52, -12.2, -0.2, 2, 4, 10.4])] >>> assert res == [1.52, 9.2, 2.0, 2.0, 4.0, 10.4] >>> tmp = tf([1]) # call with lower dimension
| Method | __call__ |
Undocumented |
| Method | __init__ |
x is defined in [lb - 3*al, ub + au + r - 2*al] with r = ub - lb + al + au, and x == transformation(x) in [lb + al, ub - au]. |
| Method | idx |
return indices of "infeasible" variables, that is, variables that do not directly map into the feasible domain such that tf.inverse(tf(x)) == x. |
| Method | initialize |
see __init__ |
| Method | is |
return True if value x is in the invertible domain of variable i |
| Method | is |
never used |
| Method | shift |
parameter solution_genotype is changed. |
| Method | _inverse |
return inverse of y in component i |
| Method | _shift |
shift into the invertible domain [lb - ab, ub + au], mirror close to boundaries in order to get a smooth transformation everywhere |
| Method | _transform |
return transform of x in component i |
| Instance Variable | _al |
Undocumented |
| Instance Variable | _au |
Undocumented |
| Instance Variable | _lb |
Undocumented |
| Instance Variable | _ub |
Undocumented |
Inherited from BoxConstraintsTransformationBase
:
| Method | bounds |
return [ith_lower_bound, ith_upper_bound] |
| Method | inverse |
Undocumented |
| Instance Variable | bounds |
Undocumented |
| Method | _index |
Undocumented |
| Method | _lowerupperval |
Undocumented |
x is defined in [lb - 3*al, ub + au + r - 2*al] with r = ub - lb + al + au, and x == transformation(x) in [lb + al, ub - au].
beta*x - alphal = beta*x - alphau is then defined in [lb, ub].
alphal and alphau represent the same value, but respectively numerically better suited for values close to lb and ub.
todo: revise this to be more comprehensible.
return indices of "infeasible" variables, that is, variables that do not directly map into the feasible domain such that tf.inverse(tf(x)) == x.
cma.transformations.BoxConstraintsTransformationBase.shift_or_mirror_into_invertible_domain
parameter solution_genotype is changed.
The domain is [lb - al, ub + au] and in [lb - 2*al - (ub - lb) / 2, lb - al] mirroring is applied.
shift into the invertible domain [lb - ab, ub + au], mirror close to boundaries in order to get a smooth transformation everywhere


Taruen | Hub
Docker containers for various natural language processing tasks
Download
Language:
Kazakh
Task:
Speech-to-text (STT)
Host machine type:
CPU only
Download


Learn to code, they say.
It’s advice that most of us have heard at school or in a newsroom, but that few of us ever really act upon.
And no, it’s not because we aren’t wired that way. We’re smart, adaptable people. The trouble with coding is that it’s so detached from what we know and what we’re good at. We’re writers, researchers, and reporters. That’s our trade. We don’t have the time or motivation to futz around with arcane syntax, any more than we have the time to learn plumbing. We’re just not interested. We’d rather be writing.
Advocates for teaching code like to go on about “digital literacy” and how important it is. They’ll tell you that you need to start learning code right this second because otherwise no one will hire you, ever, and, hey, you’re missing out, so-get-with-the-program-already. They mean well, but I’m not a fan of this line of reasoning. Not only is it condescending to call educated people illiterate for not possessing a skill outside of their field, but you won’t encourage anyone to step out of their comfort zone and learn something new by guilting them into doing it.1
Truth is, it isn’t necessary for the whole world to learn how to code. People in most professions can ignore programming entirely and not be any worse off for it. Not everyone needs to be make an app or be a badass hacker. There’s little point in code-for-code’s-sake, and less point in teaching programming to every single person in college or kindergarten, or whenever we’re supposed to have learned it.
That said, a certain kind of coding is useful for journalists who write on the web. And in 2014, that means pretty much all of us. That alone is a good enough reason to learn what practical coding is all about and how (and why) we should integrate it into our work.
Of course, that’s easier said than done. The online tutorials that exist are, for the most part, unhelpful and irrelevant. They’re out of date, teaching code and techniques that were current in the mid-00s or earlier. But even the good resources are geared toward developers and designers, not writers. They cover topics we don’t need to know about, and leave out others that we should. They don’t teach us how code can actually enrich our online writing and help us work more efficiently. (Most of us aren’t even aware that code can help us work more efficiently.)
Yes, it’s possible to code up flashy animations, interactive features, and data-stuffed bonanzas. But we can also use code on a smaller scale in our day-to-day writing. The goal of this series is to show you how.
Who is this for?
This series of posts is aimed at journalists and other kinds of writers. For that reason, it’s going to follow a different path from most “Intro to HTML” tutorials.2 You won’t learn how to build a website or app from scratch (although you could certainly go on to do just that), but you will learn languages, techniques and best practices that you can apply whenever you make content for the web.
Apart from code itself, we’re going to cover tools that can make you happier and more productive as a digital creator, such as version control, secure backups, and writing in Markdown. These topics are outside the scope of a typical web development course, but they’re incredibly useful for anyone who writes online.
If you’ve put off learning HTML at least a dozen times before, this is the series for you. If you know some web programming but begrudge having to use it, I hope I can change your mind. Code isn’t just a last-ditch resort for when WordPress is screwing up your formatting; it’s something you can learn to appreciate on its terms. That’s because it’s the simplest and most direct way of manipulating the web.
The idea is to go from “knowing” HTML to using HTML in a way that’s precise and effective. Like Miyamoto Musashi.
It’s true that getting to that stage takes some practice and time investment. But being able to work in code is worth it—not just for your resume, but to add to your personal arsenal of skills as a writer.
And if you’re already an HTML pro, stick around. You might still learn a thing or two.
What we’re gonna learn
No one who works in media needs any convincing that the web matters. In a few short years, the conversation has shifted from ‘digital” to “digital first” to “digital only.” For many of us, web has completely replaced pen and paper as our tool of the trade.
So we should probably have some idea how it works. Just as print journalists should know what happens between the time when a draft leaves their desk and the newspaper hits a doorstop, web writers should have a general understanding of the technologies that power the modern Internet. That’s why one aim of this series is to provide context by explaining things like what goes on behind the scenes in your CMS when you write a post.
But before we get that far, we have to start with the basics. That includes learning about HTML, CSS, and JavaScript, the trifecta of languages that make up the modern web. Of the three, HTML is by far the most relevant to writers, so we are going to spend many of these posts learning how to write it in a way that’s stylistically modern and clean. Afterward, we’ll talk about tools that can make writing code easier and more enjoyable—and come up with a web production workflow that you can use from your first draft right up until you hit “publish.”
The first tutorials may seem simplistic if you’ve studied HTML before, but it may be worth your while to skim them—especially if you learned HTML more than a couple years ago. The web is always changing, and web culture and technology changes with it. This series covers HTML5—the newest version of the venerable standard. It’s much like the earlier versions, but makes some important syntax and philosophical changes that affect even the most basic code.
We’ll start later this week with Part 1: Text Editing — Reppin’ It Old School
-
Yes mum, I’ll get my driver’s license soon. Promise. I know it’s embarrassing that I’m 24 and I still don’t have it. OK, technically I had it but I let it expire. But that’s besides the point. I’ll get around to it. Next month. Maybe? ↩
-
For instance, I won’t bother explaining that HTML stands for “Hypertext Markup Language.” No one has called it that since 1993. Seriously. ↩


Hospital
Home
Appointments
Lab Reports
About
Contact
Find Doctors
Back to article
Care Hospital(Example)
Home
(current)
Schedule
(current)
Lab Report
(current)
Enquiry
(current)
Emergency
24/7
Multi Speciality
Best
Pathology Labs
Best
Senior
Doctors


Thevally Palace
A place of great historic importance, Thevally Palace is situated on the banks of Ashtamude Lake. Once served as the home of Maharaja of Travancore, it was constructed under the rule of Gauri Parvathi Bai between 1800 and 1819. The striking feature about the palace is that it presents an intriguing fusion of Dutch, English and Portuguese style of architecture.
Jatayu Earth's Centre
Jatayu Nature Park is a rock-themed park which got opened on November 25, 2017. Built to promote mythology and adventure tourism, the tourism centre boasts of 6D theatre, a digital audio-visual room, cable car and ayurvedic cave resort.
Palaruvi Waterfalls
A gorgeous waterfall located on the Kollam-Shencottah Road at Palaruvi is lying at an altitude of 300 feet; the ideal time to enjoy the freshness of the waterfall is from June to January.


@@if( isProduction ) { @@include('./partial/_html_head.html') } @@if( !isProduction ) { @@include('./partial/_html_head_noappcache.html') }
Update notification
An application update has been downloaded. You can refresh this page to start using the updated version.
Your browser does not support HTML5 functionality, like local storage. Please upgrade!
Supported browsers:
|
Players: {{activePlayers}} / {{players}}
|
|
Rebuys: {{rebuys}} / {{rebuys * settings.rebuyCost}}€
|
|
Addons: {{addons}} / {{addons * settings.addonCost}}€
|
| Level | Blinds | Time | ||
|---|---|---|---|---|
| {{$index+1}}. | {{lvl.smallBlind}}-{{lvl.bigBlind}} + {{lvl.ante}} | Break | {{lvl.duration|minutes}} | |
| Level | Blinds | Time |
| Players | {{activePlayers}} / {{players}} |
| Total chips | {{totalChips()}} |
| Average stack | {{averageChips()}} |
| Rebuys | {{rebuys}} / {{rebuys * settings.rebuyCost}}€ |
| Add-ons | {{addons}} / {{addons * settings.addonCost}}€ |
| Prize pool | {{totalPrizes()}} € |
| Sharing | {{p}}% |
| {{$index+1 | place}} | {{p / 100.0 * $parent.totalPrizes()|number:1}} € |
| Current preset: | {{settings.name}} |
| Setting presets | |
| Settings | |
| Reset |
| Selected? | Preset name | |
|---|---|---|
| ✔ | ||
| Option | Value |
|---|---|
| Buy-in cost | |
| Buy-in chips | |
| Re-buy cost | |
| Re-buy chips | |
| Add-on cost | |
| Add-on chips |
| Share percentage | |
|---|---|
| Sum (should be 100): {{prizesSum(prizes)}} |
| Small blind | Big blind | Ante | Duration in seconds | Is break? | ||
|---|---|---|---|---|---|---|
| {{$index+1}} | ||||||
| Small blind | Big blind | Ante | Duration in seconds | Is break? |


{% extends "admin_layout.html" %} {% block nav %} Dashboard Expenses Income Loans Accounts Users Transfers Add Account Edit Account Account Transfer {% endblock %} {% block header %}
From {{ transfer.1 }} to {{ transfer.3 }} £{{ transfer.0.amount|currencyformat }}


Box Office Records > Domestic > All Movies > Cumulative > All Time Domestic
All Time Domestic Box Office (Rank 5,401-5,500)
See also: All Time Domestic Limited Release - All Time International - All Time Worldwide - All Time Domestic (Inf. Adj.) - Top 2016 Domestic - Top 2017 Domestic
This chart contains the top 100 movies based on the cumulative domestic box office.
Please see our All-Time Top Grossing Films Comparison for a comparison of the daily performance of all films released since 1980 that have earned more than $450 million at the domestic box office.
| Rank | Released | Movie | Domestic Box Office |
International Box Office |
Worldwide Box Office |
|---|---|---|---|---|---|
| 5,401 | 1999 | 200 Cigarettes | $6,852,450 | $0 | $6,852,450 |
| 5,402 | 1995 | Never Talk to Strangers | $6,849,998 | $0 | $6,849,998 |
| 5,403 | 1995 | Panther | $6,834,000 | $0 | $6,834,000 |
| 5,404 | 2002 | Moonlight Mile | $6,830,957 | $0 | $6,830,957 |
| 5,405 | 1994 | Exit to Eden | $6,813,570 | $0 | $6,813,570 |
| 5,406 | 2012 | The Collection | $6,810,754 | $2,079,340 | $8,890,094 |
| 5,407 | 1987 | The Chipmunk Adventure | $6,804,312 | $0 | $6,804,312 |
| 5,408 | 1948 | Easter Parade | $6,800,000 | $0 | $6,800,000 |
| 5,409 | 1968 | Hang 'em High | $6,800,000 | $0 | $6,800,000 |
| 5,410 | 1984 | Runaway | $6,800,000 | $0 | $6,800,000 |
| 5,411 | 1965 | The Train | $6,800,000 | $0 | $6,800,000 |
| 5,412 | 2010 | Conviction | $6,797,696 | $5,029,284 | $11,826,980 |
| 5,413 | 2007 | In the Valley of Elah | $6,777,741 | $17,711,409 | $24,489,150 |
| 5,414 | 2004 | Thunderbirds | $6,768,055 | $21,463,389 | $28,231,444 |
| 5,415 | 2005 | Ladies in Lavender | $6,759,422 | $12,408,873 | $19,168,295 |
| 5,416 | 2015 | Me and Earl and the Dying Girl | $6,758,416 | $2,507,764 | $9,266,180 |
| 5,417 | 2001 | The Forsaken | $6,755,271 | $0 | $6,755,271 |
| 5,418 | 1998 | Caught Up | $6,754,958 | $7,703 | $6,762,661 |
| 5,419 | 2003 | Young Black Stallion | $6,751,389 | $2,887,000 | $9,638,389 |
| 5,420 | 2002 | Seraphin un Homme et Son | $6,749,187 | $0 | $6,749,187 |
| 5,421 | 2012 | Amour | $6,738,954 | $30,048,090 | $36,787,044 |
| 5,422 | 2015 | Baahubali: The Beginning | $6,738,000 | $19,998,665 | $26,736,665 |
| 5,423 | 1986 | Nine 1/2 Weeks | $6,734,844 | $0 | $6,734,844 |
| 5,424 | 1984 | Reckless | $6,731,602 | $0 | $6,731,602 |
| 5,425 | 1993 | Fortress | $6,730,578 | $40,000,000 | $46,730,578 |
| 5,426 | 1985 | Into the Night | $6,720,160 | $0 | $6,720,160 |
| 5,427 | 1998 | American History X | $6,719,864 | $0 | $6,719,864 |
| 5,428 | 1998 | Smoke Signals | $6,719,300 | $1,037,317 | $7,756,617 |
| 5,429 | 2001 | Town & Country | $6,712,451 | $3,652,318 | $10,364,769 |
| 5,430 | 2017 | Beatriz at Dinner | $6,708,662 | $0 | $6,708,662 |
| 5,431 | 1989 | Roger & Me | $6,706,368 | $0 | $6,706,368 |
| 5,432 | 1981 | Comin' at Ya! | $6,704,127 | $0 | $6,704,127 |
| 5,433 | 1984 | Swing Shift | $6,700,000 | $0 | $6,700,000 |
| 5,434 | 1947 | Till the Clouds Roll By | $6,700,000 | $0 | $6,700,000 |
| 5,435 | 1992 | The Mambo Kings | $6,698,607 | $0 | $6,698,607 |
| 5,436 | 1997 | U-Turn | $6,690,074 | $0 | $6,690,074 |
| 5,437 | 2001 | The Closet | $6,671,454 | $0 | $6,671,454 |
| 5,438 | 2010 | City Island | $6,671,283 | $1,502,203 | $8,173,486 |
| 5,439 | 1988 | Hairspray | $6,671,108 | $2,500,000 | $9,171,108 |
| 5,440 | 1983 | Nightmares | $6,670,680 | $0 | $6,670,680 |
| 5,441 | 1994 | Mixed Nuts | $6,670,176 | $0 | $6,670,176 |
| 5,442 | 1982 | Six Weeks | $6,668,025 | $0 | $6,668,025 |
| 5,443 | 1980 | Where the Buffalo Roam | $6,659,377 | $0 | $6,659,377 |
| 5,444 | 1988 | Fresh Horses | $6,640,346 | $0 | $6,640,346 |
| 5,445 | 1986 | Black Moon Rising | $6,637,565 | $0 | $6,637,565 |
| 5,446 | 1990 | Almost An Angel | $6,633,976 | $0 | $6,633,976 |
| 5,447 | 2002 | Femme Fatale | $6,630,252 | $10,200,000 | $16,830,252 |
| 5,448 | 2007 | The Savages | $6,623,082 | $4,018,941 | $10,642,023 |
| 5,449 | 1989 | Johnny Handsome | $6,622,465 | $0 | $6,622,465 |
| 5,450 | 1980 | The Gong Show Movie | $6,621,520 | $0 | $6,621,520 |
| 5,451 | 2010 | The Last Station | $6,617,867 | $9,078,279 | $15,696,146 |
| 5,452 | 1983 | The Golden Seal | $6,609,870 | $0 | $6,609,870 |
| 5,453 | 2005 | Bride & Prejudice | $6,601,079 | $18,667,961 | $25,269,040 |
| 5,454 | 1963 | Donovan's Reef | $6,600,000 | $0 | $6,600,000 |
| 5,455 | 1946 | It's a Wonderful Life | $6,600,000 | $2,976,159 | $9,576,159 |
| 5,456 | 1984 | The Razor's Edge | $6,600,000 | $0 | $6,600,000 |
| 5,457 | 2013 | Yi dai zong shi | $6,594,959 | $51,392,340 | $57,987,299 |
| 5,458 | 2005 | Millions | $6,584,159 | $5,753,669 | $12,337,828 |
| 5,459 | 1994 | North | $6,583,223 | $0 | $6,583,223 |
| 5,460 | 2008 | Strange Wilderness | $6,575,282 | $371,802 | $6,947,084 |
| 5,461 | 2006 | Man cheng jin dai huang jin jia | $6,566,773 | $70,337,656 | $76,904,429 |
| 5,462 | 1985 | D.A.R.Y.L. | $6,561,653 | $0 | $6,561,653 |
| 5,463 | 2015 | Bajirao Mastani | $6,557,047 | $2,959,955 | $9,517,002 |
| 5,464 | 1999 | Lost and Found | $6,552,255 | $0 | $6,552,255 |
| 5,465 | 2000 | I Dreamed of Africa | $6,543,194 | $7,748,805 | $14,291,999 |
| 5,466 | 2009 | 3 Idiots | $6,533,849 | $63,000,000 | $69,533,849 |
| 5,467 | 2010 | Winter's Bone | $6,531,503 | $9,600,048 | $16,131,551 |
| 5,468 | 2004 | Maria Full of Grace | $6,529,624 | $7,911,534 | $14,441,158 |
| 5,469 | 2002 | The Rules of Attraction | $6,525,762 | $5,273,298 | $11,799,060 |
| 5,470 | 1997 | Switchback | $6,504,442 | $0 | $6,504,442 |
| 5,471 | 1956 | High Society | $6,500,000 | $0 | $6,500,000 |
| 5,472 | 1955 | I'll Cry Tomorrow | $6,500,000 | $0 | $6,500,000 |
| 5,473 | 1983 | The Osterman Weekend | $6,500,000 | $0 | $6,500,000 |
| 5,474 | 2004 | Teacher's Pet: The Movie | $6,491,969 | $0 | $6,491,969 |
| 5,475 | 1994 | The Road to Wellville | $6,487,257 | $0 | $6,487,257 |
| 5,476 | 2015 | Little Boy | $6,485,961 | $11,198,394 | $17,684,355 |
| 5,477 | 1993 | The Real McCoy | $6,484,246 | $0 | $6,484,246 |
| 5,478 | 1990 | Flashback | $6,476,134 | $0 | $6,476,134 |
| 5,479 | 1983 | Star 80 | $6,472,990 | $0 | $6,472,990 |
| 5,480 | 2004 | The Big Bounce | $6,471,394 | $154,721 | $6,626,115 |
| 5,481 | 2016 | The Young Messiah | $6,469,813 | $843,884 | $7,313,697 |
| 5,482 | 1982 | The Last Unicorn | $6,455,330 | $0 | $6,455,330 |
| 5,483 | 1998 | Gods and Monsters | $6,451,628 | $0 | $6,451,628 |
| 5,484 | 1949 | Twelve O'Clock High | $6,450,000 | $0 | $6,450,000 |
| 5,485 | 1997 | Warriors of Virtue | $6,448,817 | $0 | $6,448,817 |
| 5,486 | 2008 | Brideshead Revisited | $6,432,256 | $7,000,000 | $13,432,256 |
| 5,487 | 1995 | The Hunted | $6,420,615 | $0 | $6,420,615 |
| 5,488 | 1993 | The Temp | $6,419,876 | $0 | $6,419,876 |
| 5,489 | 2010 | Waiting for Superman | $6,417,135 | $28,931 | $6,446,066 |
| 5,490 | 2008 | The Rocker | $6,409,528 | $2,357,810 | $8,767,338 |
| 5,491 | 1986 | Just Between Friends | $6,408,791 | $0 | $6,408,791 |
| 5,492 | 1991 | My Own Private Idaho | $6,401,336 | $0 | $6,401,336 |
| 5,493 | 1995 | Mighty Aphrodite | $6,401,297 | $19,598,703 | $26,000,000 |
| 5,494 | 1981 | Eyewitness | $6,400,000 | $0 | $6,400,000 |
| 5,495 | 2010 | El secreto de sus ojos | $6,391,436 | $34,136,283 | $40,527,719 |
| 5,496 | 2014 | Cantinflas | $6,382,924 | $18,507 | $6,401,431 |
| 5,497 | 2009 | Post Grad | $6,380,019 | $181,224 | $6,561,243 |
| 5,498 | 1991 | Defenseless | $6,379,362 | $0 | $6,379,362 |
| 5,499 | 2005 | The Aristocrats | $6,377,461 | $325,143 | $6,702,604 |
| 5,500 | 2012 | Hyde Park on Hudson | $6,376,145 | $4,866,293 | $11,242,438 |
The Domestic Market is defined as the North American movie territory (consisting of the United States, Canada, Puerto Rico and Guam).
This table is updated daily to reflect the latest studio reports.
Note: This chart is not adjusted for inflation.


KJ Somaiya Institute of Engineering and Information Technology, Sion(2018-2022).
Average GPA : 7.10
Mithibai College (2016-2018)
Maharashtra State HSC Board : 66.67%
Thakur Public School,Kandivali (2004-2016).
ICSE Board : 85.83%


|
v11.20.0
|
|
Jasmine and Korra have joined the game!
|
|
v11.19.1
|
|
A bunch of new dialogue options for writers.
|
|
v11.19.0
|
|
Nagisa has joined the game! Also, a dialogue target for "alsoPlaying" has been added.
|
|
v11.18.0
|
|
Streaming-chan has joined the game!
|
|
v11.17.0
|
|
New dialogue target and filter options. As well as a simple search feature on the individual opponent selection page. Also Leela and Chell have joined the game!
|
|
v11.16.0
|
|
Samus has joined the game!
|
|
v11.15.0
|
|
Harley Quinn has joined the game!
|
|
v11.14.0
|
|
Mercy has joined the game!
|
|
v11.13.0
|
|
Mia Fey and Fred have joined the game!
|


public interface ExtendedServer
This provides the finder methods that take an explicit transaction rather than obtaining the transaction from the usual mechanism (which is ThreadLocal based).
In general we only want to use this ExtendedServer API when we want to avoid / bypass the use of the mechanism to get the current transaction and instead explicitly supply the transaction to use.
Note that in all cases the transaction supplied can be null and in this case the EbeanServer will use the normal mechanism to obtain the transaction to use.
| Modifier and Type | Method and Description |
|---|---|
long |
clockNow()
Return the NOW time from the Clock.
|
<T> int |
delete(Query<T> query,
Transaction transaction)
Execute as a delete query deleting the 'root level' beans that match the predicates
in the query.
|
<T> boolean |
exists(io.ebeaninternal.api.SpiQuery<?> ormQuery,
io.ebeaninternal.api.SpiTransaction transaction)
Execute the query returning true if a row is found.
|
<T> int |
findCount(Query<T> query,
Transaction transaction)
Return the number of 'top level' or 'root' entities this query should return.
|
<T> void |
findEach(Query<T> query,
java.util.function.Consumer<T> consumer,
Transaction transaction)
Execute the query visiting the each bean one at a time.
|
void |
findEach(SqlQuery query,
java.util.function.Consumer<SqlRow> consumer,
Transaction transaction)
Execute the SqlQuery iterating a row at a time.
|
<T> void |
findEachWhile(Query<T> query,
java.util.function.Predicate<T> consumer,
Transaction transaction)
Execute the query visiting the each bean one at a time.
|
void |
findEachWhile(SqlQuery query,
java.util.function.Predicate<SqlRow> consumer,
Transaction transaction)
Execute the SqlQuery iterating a row at a time with the ability to stop consuming part way through.
|
<T> FutureRowCount<T> |
findFutureCount(Query<T> query,
Transaction transaction)
Execute find row count query in a background thread.
|
<T> FutureIds<T> |
findFutureIds(Query<T> query,
Transaction transaction)
Execute find Id's query in a background thread.
|
<T> FutureList<T> |
findFutureList(Query<T> query,
Transaction transaction)
Execute find list query in a background thread returning a FutureList object.
|
<A,T> List<A> |
findIds(Query<T> query,
Transaction transaction)
Return the Id values of the query as a List.
|
<T> QueryIterator<T> |
findIterate(Query<T> query,
Transaction transaction)
Return a QueryIterator for the query.
|
<T> List<T> |
findList(Query<T> query,
Transaction transaction)
Execute a query returning a list of beans.
|
List<SqlRow> |
findList(SqlQuery query,
Transaction transaction)
Execute the sql query returning a list of MapBean.
|
<K,T> Map<K,T> |
findMap(Query<T> query,
Transaction transaction)
Execute the query returning the entity beans in a Map.
|
<T> T |
findOne(Query<T> query,
Transaction transaction)
Execute the query returning at most one entity bean or null (if no matching
bean is found).
|
SqlRow |
findOne(SqlQuery query,
Transaction transaction)
Execute the sql query returning a single MapBean or null.
|
<T> Optional<T> |
findOneOrEmpty(Query<T> query,
Transaction transaction)
Similar to findOne() but returns an Optional (rather than nullable).
|
<T> PagedList<T> |
findPagedList(Query<T> query,
Transaction transaction)
Return a PagedList for this query using firstRow and maxRows.
|
<T> Set<T> |
findSet(Query<T> query,
Transaction transaction)
Execute the query returning a set of entity beans.
|
<A,T> List<A> |
findSingleAttributeList(Query<T> query,
Transaction transaction)
Execute the query returning a list of values for a single property.
|
<T> List<Version<T>> |
findVersions(Query<T> query,
Transaction transaction)
Return versions of a @History entity bean.
|
void |
setClock(java.time.Clock clock)
Set the Clock to use for
@WhenCreated and @WhenModified . |
<T> int |
update(Query<T> query,
Transaction transaction)
Execute the update query returning the number of rows updated.
|
long clockNow()
void setClock(java.time.Clock clock)
@WhenCreated
and @WhenModified
.
Note that we only expect to change the Clock for testing purposes.
<T> boolean exists(io.ebeaninternal.api.SpiQuery<?> ormQuery, io.ebeaninternal.api.SpiTransaction transaction)
The query is executed using max rows of 1 and will only select the id property. This method is really just a convenient way to optimise a query to perform a 'does a row exist in the db' check.
boolean userExists = query().where().eq("email", "rob@foo.com").exists();
boolean userExists = new QContact().email.equalTo("rob@foo.com").exists();
<T> int findCount(Query<T> query, Transaction transaction)
Query.findCount()
,
Query.findFutureCount()
@Nonnull <A,T> List<A> findIds(Query<T> query, Transaction transaction)
Query.findIds()
@Nonnull <T> QueryIterator<T> findIterate(Query<T> query, Transaction transaction)
Generally using findEach(Query, Consumer, Transaction)
or
findEachWhile(Query, Predicate, Transaction)
is preferred
to findIterate(). The reason is that those methods automatically take care of
closing the queryIterator (and the underlying jdbc statement and resultSet).
This is similar to findEach in that not all the result beans need to be held in memory at the same time and as such is good for processing large queries.
<T> void findEach(Query<T> query, java.util.function.Consumer<T> consumer, Transaction transaction)
Unlike findList() this is suitable for processing a query that will return a very large resultSet. The reason is that not all the result beans need to be held in memory at the same time and instead processed one at a time.
Internally this query using a PersistenceContext scoped to each bean (and the beans associated object graph).
DB.find(Order.class)
.where().eq("status", Order.Status.NEW)
.order().asc("id")
.findEach((Order order) -> {
// do something with the order bean
System.out.println(" -- processing order ... " + order);
});
<T> void findEachWhile(Query<T> query, java.util.function.Predicate<T> consumer, Transaction transaction)
Compared to findEach() this provides the ability to stop processing the query results early by returning false for the Predicate.
Unlike findList() this is suitable for processing a query that will return a very large resultSet. The reason is that not all the result beans need to be held in memory at the same time and instead processed one at a time.
Internally this query using a PersistenceContext scoped to each bean (and the beans associated object graph).
DB.find(Order.class)
.where().eq("status", Order.Status.NEW)
.order().asc("id")
.findEachWhile((Order order) -> {
// do something with the order bean
System.out.println(" -- processing order ... " + order);
boolean carryOnProcessing = ...
return carryOnProcessing;
});
@Nonnull <T> List<Version<T>> findVersions(Query<T> query, Transaction transaction)
Generally this query is expected to be a find by id or unique predicates query. It will execute the query against the history returning the versions of the bean.
@Nonnull <T> List<T> findList(Query<T> query, Transaction transaction)
Generally you are able to use Query.findList()
rather than
explicitly calling this method. You could use this method if you wish to
explicitly control the transaction used for the query.
List<Customer> customers = DB.find(Customer.class)
.where().ilike("name", "rob%")
.findList();
T
- the type of entity bean to fetch.query
- the query to execute.transaction
- the transaction to use (can be null).Query.findList()
@Nonnull <T> FutureRowCount<T> findFutureCount(Query<T> query, Transaction transaction)
This returns a Future object which can be used to cancel, check the execution status (isDone etc) and get the value (with or without a timeout).
query
- the query to execute the row count ontransaction
- the transaction (can be null).Query.findFutureCount()
@Nonnull <T> FutureIds<T> findFutureIds(Query<T> query, Transaction transaction)
This returns a Future object which can be used to cancel, check the execution status (isDone etc) and get the value (with or without a timeout).
query
- the query to execute the fetch Id's ontransaction
- the transaction (can be null).Query.findFutureIds()
@Nonnull <T> FutureList<T> findFutureList(Query<T> query, Transaction transaction)
This returns a Future object which can be used to cancel, check the execution status (isDone etc) and get the value (with or without a timeout).
This query will execute in it's own PersistenceContext and using its own transaction. What that means is that it will not share any bean instances with other queries.
query
- the query to execute in the backgroundtransaction
- the transaction (can be null).Query.findFutureList()
@Nonnull <T> PagedList<T> findPagedList(Query<T> query, Transaction transaction)
The benefit of using this over findList() is that it provides functionality to get the total row count etc.
If maxRows is not set on the query prior to calling findPagedList() then a PersistenceException is thrown.
PagedList<Order> pagedList = DB.find(Order.class)
.setFirstRow(50)
.setMaxRows(20)
.findPagedList();
// fetch the total row count in the background
pagedList.loadRowCount();
List<Order> orders = pagedList.getList();
int totalRowCount = pagedList.getTotalRowCount();
Query.findPagedList()
@Nonnull <T> Set<T> findSet(Query<T> query, Transaction transaction)
Generally you are able to use Query.findSet()
rather than
explicitly calling this method. You could use this method if you wish to
explicitly control the transaction used for the query.
Set<Customer> customers = DB.find(Customer.class)
.where().ilike("name", "rob%")
.findSet();
T
- the type of entity bean to fetch.query
- the query to executetransaction
- the transaction to use (can be null).Query.findSet()
@Nonnull <K,T> Map<K,T> findMap(Query<T> query, Transaction transaction)
Generally you are able to use Query.findMap()
rather than
explicitly calling this method. You could use this method if you wish to
explicitly control the transaction used for the query.
T
- the type of entity bean to fetch.query
- the query to execute.transaction
- the transaction to use (can be null).Query.findMap()
@Nonnull <A,T> List<A> findSingleAttributeList(Query<T> query, Transaction transaction)
List<String> names =
DB.find(Customer.class)
.select("name")
.orderBy().asc("name")
.findSingleAttributeList();
List<String> names =
DB.find(Customer.class)
.setDistinct(true)
.select("name")
.where().eq("status", Customer.Status.NEW)
.orderBy().asc("name")
.setMaxRows(100)
.findSingleAttributeList();
Query.findSingleAttributeList()
@Nullable <T> T findOne(Query<T> query, Transaction transaction)
This will throw a NonUniqueResultException if the query finds more than one result.
Generally you are able to use Query.findOne()
rather than
explicitly calling this method. You could use this method if you wish to
explicitly control the transaction used for the query.
T
- the type of entity bean to fetch.query
- the query to execute.transaction
- the transaction to use (can be null).javax.persistence.NonUniqueResultException
- if more than one result was foundQuery.findOne()
@Nonnull <T> Optional<T> findOneOrEmpty(Query<T> query, Transaction transaction)
<T> int delete(Query<T> query, Transaction transaction)
Note that if the query includes joins then the generated delete statement may not be optimal depending on the database platform.
T
- the type of entity bean to fetch.query
- the query used for the deletetransaction
- the transaction to use (can be null)<T> int update(Query<T> query, Transaction transaction)
The update query must be created using Database.update(Class)
.
T
- the type of entity beanquery
- the update query to executetransaction
- the optional transaction to use for the update (can be null)@Nonnull List<SqlRow> findList(SqlQuery query, Transaction transaction)
Generally you are able to use SqlQuery.findList()
rather than
explicitly calling this method. You could use this method if you wish to
explicitly control the transaction used for the query.
query
- the query to execute.transaction
- the transaction to use (can be null).SqlQuery.findList()
void findEach(SqlQuery query, java.util.function.Consumer<SqlRow> consumer, Transaction transaction)
This streaming type query is useful for large query execution as only 1 row needs to be held in memory.
void findEachWhile(SqlQuery query, java.util.function.Predicate<SqlRow> consumer, Transaction transaction)
Returning false after processing a row stops the iteration through the query results.
This streaming type query is useful for large query execution as only 1 row needs to be held in memory.
@Nullable SqlRow findOne(SqlQuery query, Transaction transaction)
This will throw a PersistenceException if the query found more than one result.
Generally you are able to use SqlQuery.findOne()
rather than
explicitly calling this method. You could use this method if you wish to
explicitly control the transaction used for the query.
query
- the query to execute.transaction
- the transaction to use (can be null).SqlQuery.findOne()
Copyright © 2019. All rights reserved.


Templates Demo Site
Home
Header
Menu
Search
User Login
Footer
Menu Demo
This page contains several demos of the menu in the new BYU Header. Note that many of these are incomplete pending further development.
Six Links or Less
Our site.... in the middle of our web.
Link 1
Link 2
Link 3
Link 4
Link 5
Link 6
Here we have some content so you can see what that might look like.
More than Six Links
Our site.... in the middle of our web.
Link 1
Link 2
Link 3
Link 4
Link 5
Link 6
Link 7
Link 8
Link 9
Link 10
Here we have some content so you can see what that might look like.


Auction Preview: Magnificent Jewels at Christie's, Geneva, November 12
by BLOUIN ARTINFOWhat: Magnificent Jewels
Where: Christie's, Quai des Bergues 33, Four Seasons Hotel des Bergues, Geneva
When: November 12, 2:30 pm
Public Viewing: November 7, 2019 | 10am - 8:30pm, November 8, 2019 | 10am - 6pm, November 9, 2019 | 10am - 6pm, November 10, 2019 | 10am - 6pm, November 11, 2019 | 10am - 6pm, November 12, 2019 | 10am - 12pm
Top Lots at the Sale:
— “Exceptional Coloured Diamond and Diamond Ring,” Moussaieff — Fancy deep blue rectangular-cut diamond of 7.03 carats, pear-shaped diamonds, platinum, ring size 6 ¼, signed Moussaieff, brown Moussaieff case. GIA, 2019, report no.<PHONE_NUMBER>: 7.03 carats, Fancy Deep Blue color, VVS2 clarity, type IIb. Featured in lot 246. Estimate: CHF 10,000,000 - 14,000,000 (10,000,000 - 14,000,000 USD)
— “Superb Diamond Ring” — Cushion step-cut diamond of 46.93 carats, half-moon modified brilliant-cut diamonds of 3.64 and 3.35 carats, platinum, ring size 7 ½. GIA, 2019, report no. 10171255: 46.93 carats, D color, Internally Flawless clarity, type IIa. GIA, 2019, report no. 10098840: 3.64 carats, D color, VS2 clarity. GIA, 2019, report no. 10098837: 3.35 carats, D color, VS2 clarity. Featured in lot 250. Estimate: CHF 3,800,000 - 4,500,000 (3,800,000 - 4,500,000 USD)
— “Superb Coloured Diamond and Diamond Ring” — Fancy intense blue cut-cornered rectangular modified brilliant-cut diamond of 5.23 carats, baguette-cut diamonds, platinum, ring size 6 ½. GIA, 2019, report no.<PHONE_NUMBER>: 5.23 carats, Fancy Intense Blue color, Internally Flawless clarity. Featured in lot 202. Estimate: CHF 3,500,000 - 4,500,000 (3,500,000 - 4,500,000 USD)
— “Impressive Diamond Ring, Mouawad” — Oval brilliant-cut diamond of 23.00 carats, circular-cut diamonds, gold, ring size 6, signed Mouawad, no. Ref 1633122. GIA, 2019, report no.<PHONE_NUMBER>: 23.00 carats, D color, Flawless clarity, type IIa, excellent polish, excellent symmetry. Featured in lot 195. Estimate: CHF 2,200,000 - 3,200,000 (2,200,000 - 3,200,000 USD)
— “Sensational Sapphire and Diamond Pendant” — Octagonal step-cut sapphire of 42.97 carats, triangular and circular-cut diamonds, 4.8 cm. SSEF, 2019, report no. 108957: 42.975 carats, Burma (Myanmar), no indications of heating, royal blue, Appendix letter. Gubelin, 2019, report no. 19080020: 42.97 carats, Burma (Myanmar), no indications of heating, royal blue, Appendix letter. Featured in lot 238. Estimate: CHF 2,000,000 - 3,000,000 (2,000,000 - 3,000,000 USD)
— “Exceptional Diamond Earrings” — Pear brilliant-cut diamonds of 12.71 and 12.07 carats, circular-cut diamonds, platinum, 3.5 cm. GIA, 2019, reports nos.<PHONE_NUMBER> and<PHONE_NUMBER>: 12.71 and 12.07 carats, D color, Flawless clarity, type IIa, excellent polish, excellent symmetry. Featured in lot 174. Estimate: CHF 1,850,000 - 2,450,000 (1,850,000 - 2,450,000 USD)
— “Attractive Diamond Ring,” Harry Winston — Rectangular-cut diamond of 25.20 carats, tapered baguette-cut diamonds, ring size 6, signed Winston. GIA, 2019, report no. 16882272: 25.20 carats, D color, VVS2 clarity, potentially internally flawless, type IIa. GIA, 2008, report no. 16882272: 25.20 carats, D color, VVS2 clarity, potentially Internally Flawless. GIA, 1969, copy of report no. NY 45218: 25.21 carats, D color, Internally Flawless clarity. Featured in lot 207. Estimate: CHF 1,800,000 - 2,200,000 (1,800,000 - 2,200,000 USD)
For details, visit: https://www.christies.com
Click on the slideshow for the highlights of the sale.
Founder: Louise Blouin


February 14, 2017
Use 3 dashes for an em-dash. Use 2 dashes for ranges (ex., "it's all in chapters 12--14"). Three dots ... will be converted to an ellipsis. Unicode is supported. ☺
1 post in total
February 14, 2017
Use 3 dashes for an em-dash. Use 2 dashes for ranges (ex., "it's all in chapters 12--14"). Three dots ... will be converted to an ellipsis. Unicode is supported. ☺


meet the artists
Press
contacts
we only accept submissions by email.
please provide all relevant info and stream links only.
mocking by Jay please provide all relevant info and stream links only.
Piazza della Loggia, Brescia
0376-numero
mailto@mail.com


[gecode-users] List of pruned values
Matthew Kitching
matthew.kitching at gmail.com
Fri Feb 3 05:14:00 CET 2012
Hi all,
After calling "status" is it possible to get a list of all the domain
values pruned, or even a list of all the variables who had their domains
pruned? I am able to iterate through all variables and compare their
domains, but this is of course, not very fast.
Thanks a lot,
Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gecode.org/pipermail/users/attachments/20120202/5b0c6fd6/attachment.htm>
More information about the users
mailing list


none
0
0
Always
Espresso survey
Sample SVG and XForms - espresso customer survey
Customer Survey: Espresso
Your usual coffee drink is:
Rich, dark espresso
espresso
Creamy cappuccino
cappuccino
Long, milky latte
latte
Don't like coffee!
none
Shots of espresso per week:
Sugar?
Yes
X
Lemon?
Required for the full experience
Always
Whatever
Indifferent
Keep that citrus to yourself
Never
Send survey


Information
XDATA Year 2 - Employment dataset
XDATA
Employment
Info
Date:
Going back:
days
weeks
months
Country codes:
Group by:
Slice by:
Limit:
Count:
0