Tornado has drawn a lot of its design fundamentals from Domino, so it is a snap for Domino developers to pick up the Tornado web design basics.
There are a number of reasons why Domino developers should be interested in Tornado. A recent poll on notestips.com shows a large number of you wanting to learn about Java technology. Because the Puakma concepts are similar (only the language syntax changes) it is easy to learn. The Puakma download is small, free and will run on a very low-spec machine. The level of control over a web application afforded to a Puakma developer is much higher than its Domino brethren. Relational database connectivity, xml functionality, and server-side xsl transforms are built right in.
One key concept is that everything (except server configuration information) is stored in a relational database. All application design elements are stored here, so when you see a url path ending in .pma, it is actually refering to a set of design information in a database, not a directory structure on a physical disk. The major advantage of this approach is the easy programatic update of the design of a web application. Domino developers should consider .pma and .nsf logically identical.
The contents of a .pma "file" are as follows:
- Application information
- Roles and permissions
- Keywords (for storing, for example, runtime parameters)
- Relational Database connections (JDBC)
- Design elements
- Application documentation
Puakma cannot have the same simple ACL approach used in Domino, as the fundamental storage is different. Domino is document based so it is easy to apply the "manager", "editor" etc ACL levels to each document. Puakma, by contrast, uses a relational database where one query may update many rows in many tables, thus Puakma uses the role and permission approach. The web developer creates a number of roles (eg "Request Approver") then assigns permissions to those roles (individual names or groups). From within Actions, the Puakma developer can easily test whether the user (current session) has the role, eg: if(pSession.hasRole("Request Approver"){ ... } then do something useful based on that information.
Domino stores all its design and data in a single .nsf file. Puakma distinguishes between design data and application data, but stores the two seperately. The design data contains information about where the application data resides and can connect to multiple data sources simultaneously. This allows two applications (.pma) to simultaneously update the same data repository. Naturally, database connections are pooled.
Puakma design elements consist of the following:
| Puakma Element | Purpose | Domino Equivalent |
| Page | html, xml, xsl web pages | Form, Page, Frameset, View, Folder, Navigator |
| Action | To execute alone or against a page to provide dynamic content | Agent |
| Scheduled Action | An action that is invoked on a schedule anywhere from once a second to once every x years | Scheduled Agent |
| Resource | General web resources such as images, css, JavaScript. May contain any kind of content | Image Resources, Applet Resources |
| Library/Jar | To share code between actions. A class or jar file (containing a number of classes) | Script Libraries |
| Documentation | Any sort of documentation (eg MS-Word) you wish to attach to the database to help future developers understand this application. | N/A |
| Business Widget | Web services that belong to this application | N/A |
Actions give Puakma its raw power. When the server invokes the action, it automatically creates a session and document for you to work with. The url parameters are already parsed and so are the cookies. Actions may redirect the browser on page open and save. Binary data may also be streamed to the client (such as gif, xml or pdf data).
Sessions are handled in a similar fashion to Domino, that is all session handling complexity is hidden from the developer. Of course, if you wish to write your own single sign-on process or manual login, you can. You can write your own custom authenticator which will allow users to authenticate against anything you choose. Out of the box, Puakma uses its own database tables to authenticate against, but also available as freesource is the LDAP authenticator to enable logins against the Domino Directory.
For application vendors, one of the main drawbacks of Domino is the shipping of the source code with the application. With Puakma the developer decides whether to include the source. This makes shipping evaluation versions much safer.
Puakma works incredibly well when used in harmony with Domino. Puakma's strength is complex web apps (CRM, project management, time recording etc), where Domino excels in simple web apps (discussion forums, issues tracking, bug reporting, etc) and email. Hook Puakma into your Domino directory and mail system and your capabilities are immense.
In summary, it should be simple for a Domino developer to create applications. Puakma is incredibly open, allowing you to extend the server base (with complex server addins), the authentication mechanism (custom authenticators such as LDAP), and even the freesource webdesign.pma. There is no product like it!
To take a look at these features, install and start the server then take a look at the webdesign application http://your.puakmaserver.atyourplace/system/webdesign.pma
