The nal implementation of the CellStore/XML web client extensively utilizes principles and components introduced in section7.1.
7.2.1 Usage of parametrized links
As shown in gure6.2, there is only one web application object of class DatabaseInstanceApp that is used in the client. This object contains the element tree, which can be changed either by invoking callback blocks or by sending some parameters to it.
The links with callback are used whenever there is no need to make the action book-markable. Good example here is expansion of a node in the browser component. Page after expansion has changed only slightly, and the resulting state should not be bookmarked.
On the contrary, some requests make radical changes in the element tree, and they should be repeatable, no matter what the current state of page is. I have implemented parametrized links for this purpose.
Parametrized links are used to show a desired object. The most important parameters sent to the page are uri (Uniform Resource Identi er) and cview (component view).
When the page receives a request with uri parameter, it retrieves the corresponding ob-ject from the database and selects the most appropriate presentation component for it. Then it assigns the component with the database object as its observee, and let the presentation component initialize itself.
During the initialization, the presentation component builds its child components. It checks whether the cview parameter has been attached to the request. If not, a default view method is called. If the parameter is present, appropriate view method is called. The name of function that initializes presentation component for a particular view is de ned by a simple naming convention - initView with su x capitalized view name. This is analogous to views of standard web application objects.
The complete URL of a view looks similarly for AJAX and standard bookmarks. The example shows both types of URL for upload view for the root collection:
http://domainname/#uri=xmldb:/bookstore&cview=upload http://domainname/?uri=xmldb:/bookstore&cview=upload
7.2. IMPLEMENTATION OF CELLSTORE/XML WEB CLIENT 51
7.2.2 Caching of proxy object
When working with CellStore database, we use proxy objects for stored instances. We have already mentioned in section4.3that there is no guarantee that we get the same proxy when we request an object from the database twice. That's why there is caching mechanism in the web client.
Proxy objects are stored in a dictionary, identi ed by their URIs. So, if we need to get an object out of the storage, we rstly try to get it from this dictionary.
I have created a set of methods that make working with cached proxies simple and seamless. The two most important ones are shown bellow.
getProxyForURI:aURIString
^ self getProxyDictionary at: (aURI asString asSymbol) ifAbsentPut: aBlock value.
7.2.3 Selection of component for a model object
Selection of a component that will be used for presentation of a database object diers from the solution that Aida uses - there is a naming convention for binding presentation classes to model classes. But, in XML databases, it is quite reasonable to have presentation classes capable of presenting more types of model classes. For example, some resource types can have identical protocol, but dierent internal structure and behaviour.
For this reason, there is a mechanism for selecting the most appropriate component for a new object retrieved from the database. All classes of presentation components that can be used for representation of a database object are subclasses of class DbObjectWebComponent.
All of its subclasses have special class method observeeClass, that says which model class it is intended for.
On top of that, we have a method that can measure how much a presentation class is suitable for a model class, let's name it fitnessFor:. This method returns simply the distance between the component's observee class and a model class - the distance in the inheritance hierarchy. If the two classes are equal, the method returns 0, if the component's observee class is direct super-class of the model class, the method returns 1, and so on. If component's observee class is not ancestor of the model class at all, in nite value is returned.
Apparently, the lesser the value is, the more the two classes are similar.
With help of the fitnessFor: method, we can nd the component class that ts the model object the best and create its instance.
It's clear that this operation is much more expensive than nding presentation classes by name, but I believe this support for future subclasses is worth it. Important code fragments are in gure7.6.
"instance method in DatabaseInstanceApp"
bestComponentClassForClass: aClass
"find and return the most appropriate class for model class aClass"
|classes assoc|
"Select all web components - all subclasses of DbObjectWebComponent"
classes := DbObjectWebComponent allSubclasses.
"Find the class of component with minimum fitness value for aClass"
assoc := classes
inject: ( nil -> Number infinity ) into: [:a :c | |v|
v := c fitnessFor: aClass.
v < a value ifTrue: [ c -> v ] ifFalse: [a]
^ assoc key.].
"class method in DbObjectWebComponent"
fitnessFor: aClass
"Return the distance between aClass and the class this component is designed for"
aClass = self observeeClass ifTrue: [^ 0].
aClass = nil ifTrue: [^ Number infinity].
^ 1 + (self fitnessFor: aClass superclass)
Figure 7.6: Code for selection of the most suitable presentation component
Chapter 8
Brief User Guide
This chapter introduces the user interface of CellStore/XML web client.
8.1 Browser Panel
Browser panel is a graphical component that visualises structure of database collections and resources as a tree with expandable nodes. It is placed in the left part of the page.
Figure 8.1: Browser Panel
When an application page is opened, the whole tree is folded and only root element is visible. It can be expanded by clicking on the plus symbol (+) at the name of collection.
53
When a node is expanded, an request to the server is created that requests information about content of the collection, and the page is then updated. No data about collections are cached, so after folding a tree node and expanding it again, actual database state is shown.
If name of a collection or a resource is too long, it is shortened by showing only the pre x and su x of the name, with three dots between them. The full name is available as title of the link. See gure 8.1.
The nodes of the tree are links to various database objects. So far, supported objects are collections, XML resources and XQuery. After one of these links is clicked, a new component is shown in the main page part. The concrete type of the component depends on type of database object - all supported ones are covered in following sections.