Volgende: The bcoWeb development tool Omhoog: Technical implementation of the Vorige: Introduction Inhoudsopgave
This section provides background to web-based development and the specific tools used. First, the (programming) tools are presented: note that this section is not an analysis of all available tools9.1, it describes the tools that were used. The tools used are felt to be instrumental in getting good and quick results, though. Second, web-based development as such is explained more fully.
Python and Zope are attractive for web programming. Both Python and Zope have a big community that creates a lot of add-ons and modules that--most of them are open source--can be freely reused (`free' meaning both freedom to change and re-distribute and free of charge) [102]. An added benefit is that it provides a platform to build upon that can both be extended and, being open source, is safe to develop for.
Python code is reportedly three to five times smaller, measured in number of lines of code, than an equivalent C or Java program [105]. Assuming equal suitability to the task, this results in quicker development. And with number of bugs normally being roughly proportional to the amount code written, the number of bugs is lower than in an equivalent Java or C program [106]. These advantages make it a good language to program in, even more so when you need a first version quickly for testing purposes.
Built into Zope (and Plone) is the standard internationalisation (translation) mechanism gettext [108]. This allows the translation of the complete user interface into all languages. For the bcoWeb editor, at the moment English and Dutch are supported 100%. German (see figure 7.1) and French translations have started and are mostly complete. Note that this is just the user interface, not the BC related contents.
 |
By using the Plone user interface you can achieve a good-looking and well-working user interface even with an early prototype. The reason is that a large amount of user interface work is handled by Plone, instead of being handled explicitly by the prototype itself [111]. In cases where the default placements are not enough, a thought-out extension mechanism allows you to adapt just those parts that need adapting. This way you don't lose the rest of the automatic user interface generation that did work.
A word of advertisement for open source software is in order here. A small error in a corner case was encountered during development and a 15 minute inspection of the UML generation code (ArchGenXML) exposed the error. In the local version, the small problem was fixed and development continued. Upon submitting the fix to the maintainers, an updated version incorporating the change was issued within two days [112].
The end verdict about this set of technologies is definitively positive. The only drawback is that the Zope/Plone combination has a steep learning curve [113]. The return-on-learning-investment is well worth the cost, though. With an incredibly modest amount of work, a good-looking, attractive user interface for, in this case, a FU/TS-modeller has been made. A standard mechanism for translations is in place, inviting a translation into multiple languages. Generating a lot of code from a UML diagram saves a lot of effort.
Next, web-based software development is discussed. Web-based such as enabled by Zope and Plone.
Software is increasingly being deployed as a web interface instead of as a desktop application [114]. There are three distinct positive points to web-based applications. (1) There is no need to install applications locally. This can be a huge advantage for less-technical users and users without install privileges. Also the regular updating of applications is done away with. (2) A web interface runs everywhere. There is increasing interest in mobile applications and those devices don't run windows XP with 1600x1200. Also, you don't leave out the increasingly popular linux and macintosh. (3) Due to HTML's restrictions, the user interface is typically simpler and less involved. While an elaborate interface is needed for the likes of ArchiCad, a simpler user interface is normally preferred by the user [115].
The drawback of web-based applications is on the developer's side: he needs a skill-set that is, it appears, not too wide-spread, at least in the BC research community9.2. Much development is done in RAD tools where the principal focus is on the GUI, which ties it all together. Development for the web requires more by-hand interaction with the code. Also, running a web server permanently (or at least semi-permanently) can be more involved than a desktop application.
Web-based development has an additional advantage for prototype-stage research developments that are client-server based. Client-server requires that the data model on the server side corresponds with the model as the client understands it, resulting in a compatibility problem. Changes in the server's model do happen from time to time in an early exploration phase--like bcoWeb is in now. This leads to back- and forward-compatibility problems. In the worst case, which often happens in exploration-phase research prototypes, the server and the client have to be kept strictly synchronised, both having the correct version.
This compatibility problem can be solved by deploying applications as a web-based interface. The application runs on the server and only interfaces with the client using web pages. With the server and the application both running on one machine, coordination between the two is easy.
