Running an Apptoy application
Apptoy comes with a main class that you start from the command line.
Apptoy reads the configuration and loads the main script (the path to
the configuration is a command-line argument). This script must at least
load the main form (an XML file) which is then rendered and displayed.
From that point on, event scripts take over the control until the main
form is closed.
Apptoy is not thought to be embedded into your application or to
simply make SWT forms out of XML, it is a platform that completely takes
over control and processes all the GUI interaction - like a web browser.
While Apptoy applications work like web sites for a certain extent,
they have to be programmed like web sites: You only see the frontend
while the business logic is hidden behind calls made by the event
scripts.
However, in contrast to web applications it is not necessary to put
the business logic on a web server. It may also be put into a local
context, but Apptoy naturally supports the separation of presentation
and business logic by design.
Apptoy URIs
Within the forms, links may exist to other resources (images,
scripts, other forms). Apptoy introduces URIs that look like: apptoy://<source>/<path>
to locate the resources..
The configuration tells Apptoy how to "translate" these links into
real-world input streams, e.g. apptoy://images/abc.png
might reside on a web server (e.g. translated to http://apptoy.sf.net/abc.png
),
but it might also be available on a local file path or even as part of a
JAR delivered with your Apptoy application. Every <source>
may deliver data in a different way.
This allows a great flexibility when developing an application: You
define the actual source of the document when you start the application.
That enables you to use different ways to access the same resource
without having to change a single line of code or a form. Some examples
to make this a little bit more clear:
- you can retrieve the forms from a web server and store the images
locally.
- You can start developping an application locally (using local
files) and once you think it's time to move it onto a web server, you
move it and then you just start your application with another
configuration which reads the files from the web server instead from
the local files.
- You can collect all the images you need in one directory and make
your development work with those local files. Once your application is
finished, you may deliver the images packed in a JAR file.
- you can run the same application on different web servers using
different configurations (relative paths are not allowed in Apptoy, but
not necessary).
- You can put different parts of your application to different
<sources>
This will setup an Eclipse environment which you can use to start
your application. The following paragraphs will give a short overview
about of what parts the "Get Started" configuration consists.
-
/config.xml
The config.xml contains the configuration for the application. The
configuration contains
- ... how to translate the
apptoy://
URIs.
- ... which classes are used to render the GUI (not restricted to
SWT, custom controls and other renderers, e.g. Swing, could also be
added here)
- ... which script language is used and which modules/libraries must
be loaded
- ... where to find the main script
- ... settings like the log level
The configuration should be validated against the apptoy.xsd
file (Namespace http://apptoy.sf.net/config
)
-
/Get Started With Apptoy.launch
(Eclipse Europa
needed!)
This is the Eclipse run configuration which is used to Launch the
Application with the correct Classpath set. It uses the main class net.sf.apptoy.RunApplication
and passes config.xml
as command-line argument.
Right-click this file, select Run As->Get Started... menu item. Go
to the Run... dialog to check the details.
-
/lib
Contains the libraries used for the Get Started application. The
apptoy_* libraries are the apptoy core libraries, the js.jar
library is the Javascript library (Mozilla Rhino)
-
/xsd
The Schema files to use with Apptoy markup. This helps you to
validate your markup and to make your editor giving you a content
assist. Check your editor help how to enable the XSD files for it.
-
/gui
This is the actual application. index.js
is defined to
be the main script in the config.xml
. It contains only a
line to load the main form (more about the scripts in the Event scripts
section).
The Markup (SWT)
If you thought you'd get around SWT by using Apptoy, you're wrong.
The opposite is the case. Apptoy's SWT implementation tries to be as
close to the SWT API as possible.
This includes layouts of course... My suggestion is: Try it, it's not
that hard at all, perhaps Apptoy even gives you another point of view
because the structure looks quite logical in XML.
This introduction will not replace reading about SWT. However, you
may try to get through with only basic knowledge...
<?xml version="1.0" encoding="UTF-8"?>
<form xmlns="http://apptoy.sf.net/swt"
title="Getting started"
type="APPLICATION_MODAL"
style="SHELL_TRIM"
id="mainform"
x="1" y="1" w="400" h="200">
<resources>
<font name="Arial" height="20" style="BOLD" id="arial20"/>
</resources>
<gridlayout>
<label text="Hello, Apptoy!" font="arial20">
<griddata grab="BOTH"�horizontalalignment="CENTER" verticalalignment="CENTER" />
</label>
</gridlayout>
<script/>
</form>
The namespace (xmlns
) is important if you enabled your
browser to use the swt.xsd
file to validate your markup.
The first section of the markup is <resources>
. This
is the place where fonts, images and menus are defined. Resources are
automatically disposed when a form closes. To be able to use these
resources in the form, an id
must be defined which is then
used later (check the font
attribute in the label
element in the example).
The next big section is enclosed by the basic layout of the form (in
this case, a gridlayout
).
Controls are put within this layout, for each control, there may be
constraints that further define the position in the parent layout (griddata
in that case). One kind of controls are containers (e.g. composite
)
which can contain more controls. Containers must have their constraints
(to define their position in the parent container) and their own
layout, possible standard layouts are gridlayout, nulllayout,
stacklayout, rowlayout, filllayout, formlayout
.
The last section is the script
section. Depending on the
used language, you can insert code here directly or use the include
attribute to read it from a file (e.g. Jython is structured by indent
which is not suitable for XML files. It's better to put the script into
an external file in that case)
Using Apptoy, it's possible to initialize the backend communication
in the main script and save the necessary object instance in the session
variables (_session.put("backend",<object>)
.
Deploying an Apptoy Application
Abstract: All Jars and the configuration into one directory, create java
command-line..., explain Java Web Start deployment.
TBD: Detailed description.
Summary
This is no detailed guide to Apptoy, but I hope it helps to get
started and to understand the concept of Apptoy. Apptoy is under
development at the moment, and since I am doing all the work alone at
the moment, I have to find effective ways to provide all the needed
information.