Session Info
Arts Management Systems
David has been developing in Omnis Studio for over 6 years with Arts Management Systems. In that time he has played a major role in converting ArtsMan's main product, Theatre Manager, from Omnis 7 into Omnis Studio. The conversion, which wasn't for the weak of heart, ended up being more of a rewrite, as all the code was made more object-oriented and was re-coded to use SQL instead of Omnis Data Files. Throughout the conversion he learned how to eek out every ounce of performance from Omnis Studio using omnis tricks and small low-level externals.
In addition to Omnis he also has a great deal of experience with PostgreSQL and PL/PGSQL stored procedures and triggers and has used it to great advantage to make Theatre Manager even faster. His next frontier is to conquer threading in Omnis via Web Services and advanced C++ externals. He's always on the lookout for cool new things to integrate into Omnis to make better, faster software.
Session Info:
Topic 1: Architecture of our web server - a scaleable, ultra thin client.
The centerpiece is a loadable module we designed for Apache 2 that mimics some of the standard features of the Studio module - with a huge twist. Clients can add back end horsepower to the server to service peak requests while the server is running. In fact, every Studio license purchased by a client can be turned into an application server. Imagine 10, 100, or 1000 application servers on all forms of equipment to satisfy web demand - single threaded or multi threaded. The loadable module has the smarts to know which application servers are running, which are responding, who is busy and hand off web requests dynamically to any one of those application servers based on load balancing.
Note: if you are truly interested in implementing the approach, I am contemplating releasing the Apache loadable module, gratis, to attendees in object form.
This Topic will cover:
- the true purpose of our scaleable, thin client apache loadable module
- how we structured the application objects to make it easy to add new functionality to an API
- why the think client approach has worked for us (and for our clients) for 5 years.
Who would find this interesting:
- anybody who uses a standard thin client HTML/CSS interface to a web site
- may allow end users to customize web pages and skin their own site
- maximize their customers investment in Omnis licenses by using any license for a web server (such as after hours or peak demands)
- rapidly deliver additional web interface functions to their application
Topic 2: The PostGreSQL database. Raining Data announced PostGres support with version 4.3. We have been using the PostGres Dam with Studio 4.2 since january (in a beta agreement with RD) and have delivered PostGres solutions to a number of clients already.
Postgres has a number of very cool features and it is wonderful that Raining Data has added support for this open source database in Studio. Having used other back ends, we'd like to share why PostGres is just so cool and how to integrate it into your application.
This Topic will cover:
- PostGres installation, tuning, security, transaction, backup & performance considerations
- Considerations for using the PostGres dam
- SQL optimizations using table classes (inner and outer joins, table lookups, special functions)
- PL/PGSQL Stored Procedures
- Using stored procedures and triggers for performance
- hints around making your application back-end independent (because we had to do it too)
Who would find this interesting:
- those who have not picked a back-end yet
- if you need to use an industrial strength database on par with the big boys (like Oracle) with no cost to your clients
- if you want to discuss the capabilities of PostGres and managing it.
Topic 3: Application Architecture: making windows into subwindows or vice versa.
While converting Theatre Manager, we found that we were doing the same thing over and over again, writing the same code, making lists of data for presentation on the screen. All of this points to object re-use and it took us a while to get our objects right. Now, we can embed re-usable window objects into any other window and with a couple of methods used for communication between objects, build windows quickly with a lot of inherited capability.
While there are many ways to skin the cat, having a feature rich consistent interface for the client (and programmer) is the goal of of most of us as we deliver applications to the end user.
This Topic will cover:
- some fundamentals for creating base window classes that can be reused
- the typical kinds of messages and method interactions that we have found to work
- a method of object interaction that allows for most parameters in any order
- how to stick it all together into one package for rapid application development
Who would find it interesting:
- everybody building with an object oriented language has to go through the process of object design, finding out what's good or bad, go down dead ends and come back to the right place. There are many approaches and we are open to sharing what worked for us and why.
- we are prepared to talk about anything: objects, references, lists, helper methods, table classes, database interaction, GUI features, table driven interface (you name it) because the techniques used could be of benefit to others - including opening our code to show how we did almost anything.
Topic 4: Performance Analysis.
Want to learn how to tweak Studio in certain areas to optimize your code and achieve some dramatic performance gains? Want to find out where Studio is spending all of its time executing your code and were to spend your optimization efforts?
This session will focus on techniques that we've discovered to enhance the performance of Studio in areas of list management, list searching, string manipulation, parameter passing, object and field references and other 'best of' coding practices that help you deliver a high performing application to your customer.
We will also provide an easy to implement performance analysis library that uses the new performance analysis facilities in Omnis Studio 5 and walks through some examples of where the tool can be used, what it displays, and how to track (and prove) performance gains made in an application.
Topic 5: Accessing Open Source Code as Objects in Studio.
One of the wishes in the Omnis community is to be able to access open source code within studio. It is certainly possible using the external API to create your own external components. Attendees will receive an example library and a walkthrough that lays out all the basics for how to create an external component with non-visual objects. The example library comes with complete projects for Windows and Mac and, more importantly, a file structure and project setup that allows simple compilation for multiple platforms and is compatible with version control systems.
We will be using the JSON library as an example (which is an alternative communication method to XML) that is used by many web developers for sites like Facebook - because it is less wordy and faster than decoding XML.
It is possible to access other open source or freely available libraries such as decoding winmail.dat, talking to apple's Sync services, or making your application 'Bonjour' aware to locate postgres databases on the network, etc. All this can be done if there are published API's for these non-visual objects with a little C++ knowledge.
This session involves discussion of the externals interface for non-visual objects only. We highly recommend participating in Michael's or Kelly's sessions prior to attending this session.
Topic 6: Writing code to use oXML.
XML is a commonly used as a communication protocol to talk to web sites, access preference files and/or store data.
In this session we'll use two practical examples (and source code) using oXML. One example will be our performance analysis tool which uses XML both for storing data and retaining preferences in a preference document in standard XML format.
The second example will use oXML to decode the response from google mapping api. We use this to geo-encode the latitude and longitude of addresses in our customer databases and use that for determining distance from a fixed point (a marketing use) and/or to map customers onto a static google map.
While oXML is the focal point of this session, both source code examples are worth while in their own right
back to top
Back
