Main

The Vordos Manifesto

A brief introduction to what we are trying to achieve.

Current application development techniques waste time and energy

It’s been more than 30 years since the first GUI applications were written. Since then, a lot of people developed many different programming paradigms and tools to make the development of such applications easier: object-oriented programming, visual GUI designers, scaffolding frameworks, noSQL, object-relational mapping… However, and in spite of all these advances, GUI application development is still time-consuming and error-prone. In order to produce a simple data-driven application, the modern programmer has to perform a set of laborious and largely unnecessary tasks:

  1. Design an adequate data model, either on paper or using a CASE tool.
  2. Build a graphical user interface, using a GUI builder or a widget library.
  3. Develop algorithms that handle and manipulate the application’s data (if necessary; a large proportion of applications are used solely for data input and reporting).
  4. Write event-driven code to tie everything together.
  5. Test and debug.

This is a big burden for the developer’s shoulders, and it becomes even bigger if one considers the need to maintain a certain commonality and level of documentation, to make sure that the program will remain maintainable and easy to understand by others.

The Vordos Project aims to remove all this donkey work from the developer’s shoulder.

The ideal application development framework

Vordos will enable developers to produce functional Rich Internet Applications (RIAs) with only minimal input that will be provided in 3 discreet steps:

  1. A detailed (and fully documented) data model.
  2. A few lines of code that provide a general idea of what the GUI will look like and how it will behave.
  3. The algorithms that handle and manipulate the application’s data (if any).

This process, which matches the popular MVC architectural patern, is made possible by the various sub-projects of Vordos:

  • Vordos Rejasca
    A modern and extensible RPC server that comes complete with its own (JSON-based) IDL and a flexible security system.
  • Vordos Baliso
    A set of libraries and scaffolding tools, based on Rejasca and Ext-JS. Among other things, Baliso provides facilities for data peristence and for rapid generation of graphical user interfaces.
  • Vordos Deplorio
    A set of tools that facilitate the deployment of Vordos applications to web servers (if they are to be used as RIAs) or to software packages (such as .deb or .msi) that can be installed on a desktop operating system.

Aphorisms

Providing developers with the easiest possible way of creating a GUI application is not an easy task. Thus, having a set of philosophical guidelines to govern its development can be extremely helpful. This section highlights a few of those (and is subject to grow).

  1. Quality software isn’t measured in lines of code. And it can’t be written in a week, either.
    Developers should make sure that their code is as simple as possible, even if this requires a major rewrite, a shift to a different programming paradigm, or a long break to think things over.
  2. There are many evil programs in this world, but code generators are among the worst.
    Even though Vordos will use some of the principles of scaffolding to achieve its goals, this must be achieved by the use of run-time libraries, not code generation. Building a ten thousand line app out of a few definitions may sound impressive, but allowing our users to create 100 line apps that do the same thing is even better, and more likely to keep those users sane.
  3. Be restrictive when you must, and permissive when you can.
    An aphorism that must be kept in mind when defining the project’s APIs and data interchange languages. For instance, requiring the user to provide a description for every type he defines in ReDL is considered a good thing, as those descriptions can then be used to build the application’s GUI in a hassle-free way. At the same time, restricting the number of properties an object type will have is probably bad practice, as it will limit the user’s productivity.
  4. Always store data in a readable format.
    When storing data in a relational database, developers should create sensible schemas and give their tables and fields meaningful names. Using the EAV model is definitely not a good idea.
  5. Define and follow some reasonable coding guidelines. And document your code.
    This, of course, is a must for every software project. Incidentally, these guidelines are already defined and can be found here.