There are some standard problems that web developers have to deal with. One of them is the design of communication with server, parameter passing and URL handling.
• We will need the back-button support, because users have got used to it and it will by probably heavily used when browsing collections.
• The views should be Bookmarkable, so that they can be sent to another user over email, for example.
The implementation has to follow these requirements, otherwise working with the client will be cumbersome and erroneous.
Chapter 6
Design of the web client
In spite of recommendations about web application design that Aida framework includes, there is not a single way only to create the web client to CellStore XML database. As Smalltalk is very customizable, there are many ways.
I was faced with a kind of dilemma. Use Aida's standard approach, or extend it with some custom classes and change some of the core principles a bit? This dilemma resulted in two dierent designs. The rst one was partially implemented, but contained some limitations, so I have decided to extend the framework and to implement the client on top of the extension.
6.1 The rst, straightforward design
This design conforms the recommended Aida rules. There is one presentation object per one model object, following the naming conventions. Figure6.1shows the inheritance hierarchy of classes, which resembles the hierarchy of model objects. It is quite common that similar objects has similar representation, but generally the presentation classes do not have to conform the model hierarchy. In this case, there is class CellStoreApp, that is super class of all presentation classes, but is not super class of all model classes. It can contain some common methods, for example the ones that generate components that are used in more types of presentation objects, but can be never associated with an model object - observee.
6.1.1 Description of presentation objects
The design of presentation classes is quite intuitive. If there is a set of classes of model objects, we just prepare a set of corresponding presentation classes (and some extra ones, for better abstraction).
• CellStoreApp is a class mentioned above that is not associated with any model class, but contains common methods.
33
Figure 6.1: Classes in the rst design
6.1. THE FIRST, STRAIGHTFORWARD DESIGN 35
• DatabaseInstanceApp can contain controls for administrative operations for the whole database. There are no controls or settings provided by CellStore core yet, so this class has no special meaning for now. But as DatabaseInstance is a base class that represents the database as a whole, DatabaseInstanceApp serves as an entry point to other classes.
• CollectionApp presents a collection stored in the database. It is used for listing child collections and resources and importing new resources.
• ResourceApp is where common methods for all types of resources are placed, but can be never used for presenting a model object (there is no instance of Resource) in the database.
• XMLLikeResourceApp is similar to ResourceApp, but is more speci c to resource that can be handled as XML documents and fragments.
• XMLResourceApp instances are assigned to XML resources. They can show the contents of these resources.
• XQueryResourceApp are similar to XMLResourceApp, because result of an XQuery is an XML resource, but this class can also show the de nitions of the queries.
• XQueryInterpreterApp is there for evaluating XQuery expressions and returning re-sults.
6.1.2 Views of presentation objects
Each model class that we need to present about has assigned one presentation class, which is presented as a web page. If we need more views for an object, we can use standard Aida's page view. Good example is a XQuery resource, that can be presented as de nition - an XQuery expression, or as a result of that expression. There are more presentation classes that need more views. Full description of classes and their views is in table6.1
Presentation class Views
The browser component has to let the users quickly explore the hierarchy and contents of collections in the database. This structure can be quite complicated, and only a small part of it is in the interest of the user at a time. Therefore, it is suitable here to implement it
as a foldable tree, whose nodes can be expanded on demand. In this case reloading of the whole page would be too slow and unnecessary, so we will use AJAX updating here.
We have to create a new component class for nodes of this hierarchy tree. This class has method prepare that is called after each AJAX request and that updates the component (self). This method must be set as in the component's method instance variable.
The prepare method removes all child elements of its object, and creates the content of this component again, depending on the state of the node - it can be expanded or folded. If it is expanded, it will contain list of children (links to collections and resources), otherwise not.
The part that causes folding and expanding of the tree nodes is the one where the element that can update this tree node element id added. The code can look like this.
self expandable ifTrue: [
node text: ( expanded ifTrue: ['-'] ifFalse: ['+'] ).
node onClickUpdate: self.
].
Although this solutions seem elegant, there are still problems already described in section 3.3.3. What's more, this hierarchical structure that contains many elements that are updated by the same method is likely to suer these problems quite often.
Another problem is that the browser panel cannot work on web browsers without JavaScript support, which means that we are dependent on it (there is no simple way how to overcome this, I suppose). But, when we are dependent on JavaScript and AJAX support, why not to use it more, to make the application respond quickly?
The last question has made me think about enhancing of Aida with some elements, that would make AJAX updates as easy as possible. And to redesign the application almost from scratch.