LZadmin

Web Data Admin Tool Generator

LZadmin is a program which generates a complete web based, forms driven database administration application. Data entry forms and search result display lists are created based on information derived from the database itself. A working application is generated based on code templates in LZadmin, so no programming is required. A user provided configuration file allows definition of customization and deployment options.

LZadmin also provides a simple and easy to learn Data Definition Language for those who need to create a database from scratch or want to enhance an existing schema. This can be as simple as writing a dashed list of field names and types.

The main features of LZadmin include:

• The generated client Graphical User Interface (GUI) provides the necessary create, read, update and delete (CRUD) functions.
• Easy and flexible forms based object finder methods are also generated.
• Search result lists are sortable numerically or alphabetically.
• The GUI is an OpenLaszlo client which runs in a web browser under a Flash plugin. This technology provides a rich and smooth user experience more akin to a desktop application than a typical browser based application.
• Multiple forms or lists can be open simultaeously for different data classes allowing easy cross reference.
• LZadmin generates a middleware Data Acess API accesible through standard Web Services.
• LZadmin middleware runs under Ruby On Rails which provides the Web Service and Database Access layers.
• An easy to learn YAML based Data Definition Language may be used instead of SQL to create the initial database schema.

Here are links to diagrams of the Code Generation Process
and Deployment Architecture.

User Guide

For more information on the product and how to configure LZadmin to generate your Admin Application, please refer to the User Guide.

LZadmin Release Status

Development of LZadmin has been deprecated in favor of development efforts on the FrontRail product. The main reason for this is that use of SOAP Web Services significantly complicated both the code base and the deployment of the product. Much of the code base and design, however, has been instrumental in the development of the new product.

Although there are many benefits to the Adaptive approach to GUI component creation taken by FrontRail, there are some benefits to a static code generation approach taken by LZadmin, especially when the database schema is very stable. The most obvious benefit is that the compile time code generation approach can reduce the intial load time for the running application.

Genacode plans to introduce a FrontRail variant in the future which uses the RemoteObjects protocol, but also uses template based code generation for faster startup.

If significant demand for LZadmin becomes aparent we may continue support on an individual customer basis. If you would like more information about LZadmin please contact us and let us know of your interest and needs.

FrontRail

Dynamic Web Database Admin Tool

FrontRail is a Web Database Aministration Tool built with OpenLaszlo Rich Internet Application (RIA) client technology and Ruby On Rails middleware. It provides a Flash based multi-window interface for data entry, search and display. On startup the client running within a browser self-configures to work with any Rail’s hosted database (with the necessary FrontRail plugins installed). Rails config files may be used to specify customization and deployment options.

FrontRail uses the Genacode RemoteObjects protocol which provides an RPC communication mechanism between the OpenLaszlo and Rails environments. With RemoteObjects, OpenLaszlo clients can run in SOLO mode which allows direct communication between the Flash program and the Rails web server.

The main features of FrontRail include:

• The client GUI provides the necessary create, read, update and delete (CRUD) functions.
• Flexible forms based object finder methods are provided.
• Search result lists are sortable numerically or alphabetically.
• Multiple forms or lists can be open simultaeously for different data classes allowing easy cross reference.
• The GUI being OpenLaszlo based, provides a rich and smooth user experience more akin to a desktop application than a typical browser based application.
• FrontRail middleware runs under Ruby On Rails which provides the Active Record database interface.

FrontRail Demo

The FrontRail Demo allows users to interact with a live database.
Please try it out.

If you would like more information about FrontRail
please contact us and let us know of your interest and needs.

OLORE – OpenLaszlo Over Ruby Environment

Genacode is in the process of creating a novel OpenLaszlo over Ruby Environment (OLORE) which allows the OpenLaszlo Rich Internet Application client technology to interoperate with the popular Ruby on Rails web framework. Here is an OLORE Overview presentation.

Genacode has founded the OLORE Open Source Project to encourage community use of and contribution to core components of this technology. This wider use should help accelerate its refinement and broaden its applicability.

The OLORE concept is built around the RemoteObjects communication protocol. This allows OpenLaszlo Solo clients to communicate directly with Ruby class objects hosted in a Rails environment. Some Ruby classes with general usefulness as Services are provideded as additional Rails Plugins. The result is a modular Environment where commonly required Services may be selected for use. Developers may also easily develop and add their own application specific server side classes.

The following components are being made available as Open Source in the RubyForge OLORE project:

• Rails Plugins:
  • RemoteObjects – API/README Rdocs.
  • AdminService – API/README Rdocs.
• OpenLaszlo Library:
  • RemoteObjects – API docs not yet available, but you can browse the source under trunk/laszlo/lib

Here are the 0.0.2 Release Notes

RemoteObjects

RemoteObjects is an HTTP based protocol allowing object-oriented access to remote Ruby classes. The implementation provides an OpenLaszlo client library and a Ruby on Rails plugin on the server. The current release uses Javascript Object Notation (JSON) as the HTTP serialization format (XML support is planned for a future release).

RemoteObjects Protocol for OpenLaszlo and Rails (0.0.2)

RemoteObjects supports the invocation of both Ruby class and instance methods. Use of class methods is a natural and easy way to provide RPC style stateless web services where every client would see the same service API.

RemoteObjects also supports the remote instantiation of class objects whose lifetime may be either the duration of a single request or the lifetime of the session. Use of instance methods is useful for creating objects where each client may have a separate object with its own state or where a single client may have several instances of the same object.

If an object is designated as a session object, its state is stored in the client’s session between requests using whichever session store is configured in Rails. Object reference handles are returned to the OpenLaszlo client which then can invoke methods on these statefull objects.

Regular Ruby Classes can be used with RemoteObjects without necessarily deriving from a special class. An object is treated as a Session Object by the controller if it’s Class is listed in a RemoteSessionClasses array (or alternatively it may derive from the SessionObject Class to get this treatment). The Rails RemoteObject controller automatically restores and saves the attribute state of Objects around HTTP requests if it is identified as a Session Object.

Programmatic use of Remote Objects is straightforward. On the server, Ruby Classes simply need to be made available, e.g. by putting them in the “lib” directory or by including a reference to them. They also must be enabled for remote access by listing them in a RemoteClasses array. Class names may have Module name prefixes which is helpful for avoiding name collisions, e.g. “MyModule::MyClass”.

On the client, the required OpenLaszlo Classes are:

• remote_server to define the (host, port, format) to use and handle remote communication.
• remote_class to define the class name and invoke class methods.
• remote_instance to hold a reference to the remote object once it has been instantiated and invoke instance methods. A Client Library User Guide is available for more details.

Automatic data-binding to all standard OpenLaszlo components is provided as part of the product. If the OpenLaszlo object which owns the request has an attribute named “dataobject” then any data received is bound to the “dataobject” it refers to. In this case, JSON objects received from the backend are translated directly into the OpenLaszlo DOM tree during binding which eliminates the need to translate to XML first. A “dataoptions” literal object may also be defined to control specifics of the databinding operation.

One of the benefits of RemoteObjects is that it is able to operate in OpenLaszlo Solo mode rather than Proxy mode. This means that the client machine can communicate directly with a Rails web server without the need for the Lazlo Presentation Server (which runs in a Java servlet container) acting as an intermediary. This greatly simplifies server deployments and opens up many possibilities for deployment scenarios.

This Slide Presentation provides an overview of the functionality, info on the client APIs and some design details.

RemoteObjects is currently being used as the RPC mechanism in the FrontRails product. This Demo allows a user to interact with a set of backend Ruby Classes and Objects.

FrontRail Demo

This Demo application provides a set of tables which might be used in a Software Product Purchasing application. It is not intended to represent a complete application, but rather a good introduction to the capabilities of FrontRail.

You may login with:

Username: admin
Password: lzadmin

RemoteObjects Demo

This Demo is a test fixture which allows manual exercise of the RemoteObjects capabilities. The demo program has access to the following Ruby Modules::Classes on the server.

• TestJsonXml::DataPatterns – Test cases for the basic JSON to XML conversion patterns.
• RemoteTest:: – Various test classes: Rtest, Stest, SOtest, SOItest (see code for description).

Here is the primary source code file for the demo program.

TestRemoteObjects Usage (0.0.2)

The program provides the ability to load remote classes and invoke their class methods
or instantiate remote class objects and invoke their instance methods.
The Debugger console displays data sent and received during testing as well as some
useful processing info.
The user interface is fairly self-explanatory. The following notes further explain
how to control the processing.

To load a Remote Class:

• Enter the ClassName or ModuleName::ClassName if necessary.
• Click the ‘Load’ button to load the Class into the client.

If the class load is successful a set of new rows will appear below the first set
which control operations on the remote class
(if multiple classes are loaded some may be hidden by the Debugger console
which can be moved out of the way).
The initial rows for the class contain:

• The class name.
• An input field for a method to call.
• An input field for any parameters to pass with the operation.
• Two buttons, to either ‘Invoke’ a method or to instantiate a ‘New’ object.

To call Class Methods:

• Enter the method name after the ‘Method’ label.
• Enter a comma separated list of parameters after the ‘Params’ label.
• Click the ‘Invoke’ button.
• Results of the call will be displayed in the debugger window.

To create New Instances:

• Enter any initialization parameters (comma separated) which might be needed.
• Click the ‘New’ button to create the new remote instance on the client and server.
• A successful ‘New’ operation creates a new group of items to the
  right of the new instance widgets. Multiple instances can be created
  resulting in more input widgets further to the right.

To invoke a method on an Instance:

• Find the data entry fields and ‘Invoke’ button under the Instance Number and Object ID
  you want to invoke.
• Enter the ‘Method’ name to invoke.
• Enter any desired Parameters (separated by commas to pass to the method).
• Click the ‘Invoke’ button to invoke the method.
• Observe data sent and received in the Debugger Console.

To bind recieved JSON data to a Laszlo Dataset:

• Enter any Dataoptions desired in the input text field at the top of the page.
  Use literal object syntax with curly brackets and double quotes around option keys,
  example: {"expand_array": false}. See below for the options definitions.
• Click the ‘Data On’ button. The data binding will be applied to any subsequent Invoke operations.
• After an invoke which returns data, you may inspect the Dataset
  by clicking the “i” button to the right of the ‘Data On/Off’ button.
• To disable, Click the same button which is labeled the Data Off button when binding is in effect
  and Data On when it is off.

The Dataoptions available are:

• “expand_array”: (true|false) – True means expand arrays into multiple nodes using the
  tag name of the parent at the parent level. Default value is true.
• “array_tag”: String – Tag name to use for arrays when not expanded.
  The tag name ‘item’ is used when ‘array_tag’ is not specified.
• “root_name”: String – Name to use for the root tag name instead of the default ‘element’.
• “bind_children”: (true|false) – True means bind the children of the root node to the Dataset, else bind the root node. Default value is false.