Determining the behaviour of an application at run-time using parameters is a well-established practice. But whilst it’s possible with command-line and server-side applications, the scope for passing information to client-side internet applications is limited. With the growth in internet-facing desktop applications, widgets and gadgets, there is a need to pass parameters directly to the application, rather than via a server, and this post looks at how that might be achieved.
To illustrate, we can use the Unix command
ls to see the contents of a
directory, and add switches like
-las to change the behaviour:
Similarly, on the web we can pass parameters to server-side applications, using query strings:
Let’s look at how something similar might be done on the client.
We already have a mechanism to pass variables to a client, via the URI, and
that’s the XPointer Framework. I’ve
described before how we use this technique in UBX
Viewer to pass parameters that are to become
link values; as UBX Viewer loads it uses these settings to configure itself.
But there are a number of reasons why we now need something more general purpose, and it can easily be based on the same principles.
The technique we’re using with the Ubiquity
libraries is to pass information to be used
by the client in the
For example, if we have a slideshow application, and want to create a bookmark for the third slide, we might just do it like this:
However, if the application is also able to indicate which theme should be
used, it is better to have the capacity to set more parameters, which
Another example of how run-time information might be passed concerns XForms applications.
In XForms it is possible to indicate the data to be used in the form by using
instance element. The element can either hold information directly:
<xf:instance> <details xmlns=""> <name>Harry Angstrom</name> </details> </xf:instance>
or via an external file:
<xf:instance src="data.xml" />
However, when creating a generic application the initial data will inevitably
be different for each user. In this situation we can use another XPointer,
This has the effect of populating the default instance in the default model,
with an element called
name, using the same rules as described in XForms
The final way that we might want to specify data at run-time is to indicate
@src value of an element, so as to cause a different file to be loaded
For example, if we wanted the instance data to be loaded from a different
location, we would ensure that the instance has an
@id value in the
<xf:instance id="p" src="" />
and then specify the data source in the URL:
As the number of client-side internet applications grows there is an increasing need to make them flexible. Passing run-time parameters via the URL is one way this can be achieved.