GLG图片服务器是一款瘦客户端解决方案,它能通过使用AJAX技术在网页上显示动态实时图片。并且能代替胖客户端操作方法,只需使用客户端上最小限度的功能。
通过基于瘦客户端方法的AJAX,当大部分应用程序进程在中心服务器上运行时,客户端能实现只需使用行业标准HTML与JavaScript显示前台的功能。为显示基于输入数据而动态更新的图片,服务器需要根据每个图像需求转化图片的图像。
The GLG Graphics Server is a thin-client solution for displaying dynamic real-time graphics on a web page using AJAX technology. It is an alternative to the thick client approach and requires only minimal capabilities on the client.
With the AJAX-based thin client approach, the client side serves as a display front end that uses only the industry-standard HTML and JavaScript, while most of the application processing is performed on the central server. To display graphics that update dynamically based on the input data, the server needs to render the image of the graphics on each image request.
Interactive Graphical Editor
The dynamic graphical screens displayed on web pages are created interactively using a graphical editor - the GLG Graphics Builder. Using the Builder, a developer can draw graphical objects, define their properties, as well as attach dynamics and define resources for animating the drawing with real-time data. The drawing is saved into a file and used by the Graphics Server for image generation.
In addition to creating drawings from scratch, the Graphics Builder provides palettes of pre-built widgets, such as dials and meters, graphs and process control symbols, which can be added to the drawing using Drag and Drop. The Builder also allows the user to define custom symbols and add them to a palette as reusable components.
With the help of the Builder, the job of creating and maintaining graphics, from simple dashboards to complex visualizations and custom HMI screens, is done in an interactive, point-and-click environment. The graphics may be easily edited in the Builder with no programming involved. Once the updated drawing is saved, it is ready to be used by the Graphics Server without recompiling the source code.
The GLG drawings are screen-resolution independent and may be scaled at run-time, as shown in the demos. The same drawing may be used to render images of various resolutions depending on the size of the client's screen.
Custom AJAX Dashboards
The drawings created using the Graphics Builder represent the dynamic graphics displayed on the application's web pages at run time. For example, to create a custom AJAX Dashboard displaying a few graphs and meters you can simply open a new drawing in the Graphics Builder, add a few graphs and meters to it from a palette, name them for run-time data access and save the drawing.
While in the Graphics Builder, you can also change object properties, edit the object layout on the page, add custom labels and annotations or draw custom decorations using the Builder's gradient, shadow and transparency effects.
An alternative way to build an AJAX Dashboard is to combine several widgets on a single HTML page, as shown in the GLG AJAX Dashboard demo. Each self-contained widget is using its own server-side servlet and it may be deployed as a reusable component on multiple web pages.
In addition to simple dashboards, elaborate custom graphical displays may be created in the Builder and deployed on a web page, as shown in the demos.
Run-Time Image Generation
At run-time, the Graphics Server loads the GLG drawing and uses it to generate dynamic images, updating the drawing with the current data before processing each image request. The drawing contains definitions of all graphical objects and their dynamic actions. Once the drawing is loaded, it is used to generate web images over and over without the overhead of recreating the graphics on every request, resulting in superior server performance.
When a client issues an image request, the Graphics Server creates a snapshot image of the drawing using the current data. An image request may contain parameters that define an image size, a value to be displayed in a dial, a title for a graph or other custom attributes. For example, in the process control demo the image request contains the show_pipes parameter. If this parameter is set to 1, the generated image will display pipes connecting the tanks. The image generation parameters are passed to the Graphics Server using the standard URL parameter syntax.
Before generating an image, the Graphics Server updates the drawing with the current data by setting the drawing's resources. The resources are defined in the Graphics Builder when the drawing is created and accessed by the servlet at run time using the SetResource() API method.
When the drawing is updated, the servlet generates an image by simply invoking the CreateImage() API method. This single method of the Graphics Server takes care of the complicated task of rendering all objects in the drawing in their current dynamic state.
Click here to see an example of a URL showing a dynamically generated image. Reload the page to see new data or change the width/height parameters of the URL to change image size. A "&show_pipes=1" parameter may be appended to the URL to activate the pipe display. In an application, a JavaScript timer may be used to reload the image periodically to display new data as shown in the demos.
Servlet Customization
In the JSP environment, the Graphics Server is deployed as a GLG Servlet - a 100% pure Java servlet that may be used with any compliant Java2EE Application server.
The source code of the servlet is provided and may be customized by the application developers according to the application requirements. For example, the servlet may share one drawing between all servlet instances or create a separate instance of the drawing for each servlet session.
When a custom drawing is used, the servlet code may be modified to set the application-specific resources defined in the drawing, as well as handle an application-specific user interaction.
The GLG Servlet uses the GlgServer.jar class library that contains GLG Toolkit's object and rendering engine. The class library provides both the GLG Standard and Extended APIs described in the documentation of the GLG Java classes. The GLG Standard API provides methods for accessing resources to update the drawing with real-time data. The Extended API provides methods for advanced features, such as creating objects programmatically or querying a list of all resources defined in the drawing. For example, the Extended API may be used at run time to create a variable number of dynamic icons representing airplanes as shown in the GIS and AirTraffic Control demos.
Dynamic Data Supply
In an application, the servlet can query data from any data source, such as a PLC or process database, using JDBC, Java OPC or any other preferred data connectivity API. Alternatively, the data may be supplied by the HTML or JavaScript via the parameters of the image URL.
The servlet updates the drawing with the new data by setting the drawing's resources using GLG's SetResource methods. The resources for animating the drawing with data are defined in the Graphics Builder when the drawing is created.
For example, in the drawing used in the process control demo, an object named "Heater" has a resource named "HeaterLevel" that controls the fill level of the heater's tank. When the drawing is used in the servlet, the servlet updates the fill level by using the "Heater/HeaterLevel" resource name as follows:
SetDResource( "Heater/HeaterLevel", heater_level_var );The use of resources helps to separate graphics from the programming logic. The application simply sets a logical resource named "Heater/HeaterLevel", and the GLG's graphics engine takes care of all low-level details of rendering the objects' graphics.
AJAX-Based User Interaction
In addition to generating dynamic images, the servlet may handle user interaction by processing AJAX-based requests for object selection, tooltips and user input, such as pressing buttons in the drawing with the mouse. These features are demonstrated in the process control and other demos.
To handle user interaction, JavaScript is used in the application's web pages to add onclick and onmousemove event handlers to the image. When the user clicks on the image or moves the mouse over it, an event handler is invoked in the script. The event handler sends an object selection AJAX request to the Graphics Server, passing the mouse coordinates as parameters of the request. The Graphics Server processes the request by finding an object selected by the mouse coordinates. The servlet may process the selection on the server side or return the selection information back to the client for processing.
The client may use the output of the selection request to popup a tooltip, display the name of the selected object or execute a drill-down action. For example, the process control demo displays a dialog with the object's data when the object is selected with the mouse. A tooltip is displayed when the mouse is moved over a named object in the drawing. If the Show 3D Pipes button at the bottom of the drawing is pressed, the pipes connecting the tanks and valves will be displayed in the image.
The tooltips and object selection events are processed by the GLG Graphics Server's engine on the server side, with no image maps or vector objects created in the browser on the client side. This technique handles a large number of vector objects in the drawing without the HTML performance limitations related to a number of used image maps.
Click here to see the full source code of the GLG Servlet for generating images and handling user interaction requests.
Since the selection and tooltip events are processed on the server side with no image maps embedded in HTML, the HTML pages do not need to be regenerated when the geometry of the objects in the drawing is changed.
The server-side processing of selection events is the only practical option when the drawing contains dynamic moving icons, as shown in the Airtraffic Control Demo. In this case, generating static image maps for the icon selection is simply impossible, since the icons change their position. Using AJAX to generate image maps dynamically every time the icon moves, would be also impractical due to the performance limitations. This leaves the server-side selection processing as the only practical alternative.