Link-Resolving Components
A problem for the GUI is how to retrieve a HyperLink from a user's action. There are unlimited ways to extract a HyperLink because different methods may be needed in different contexts. For example, in a Web browser, clicking an anchor(A) causes the destination HTML document to be retrieved and displayed. The location of the destination is stored in the value of the HREF attribute of the anchor. This is easy to get. Suppose that the Web browser is extended so that it can used as a hypertext dictionary if the preference is set. The definition of a word would be displayed if the user clicks on that word. This time, if the location of the definition of each word is put into the attributes of each word, it would take up a lot of space. Even if we can afford to do that, how about if the acronym is displayed by setting to another mode? Therefore, it is inefficient to put all the links in Hypertext. There are two problems with static, explicit links[from Tompa]:
- ...In general, large texts have too many links of too many
different types to be able to create them all manually, store them explicitly, and display them all iconically. Even if one were able to do so, the density of interconnection would overwhelm most users...
- ...explicit links... presuppose that the link's target is
fixed, given its source... However, the steps to take after a
user's action depends on the current context of the hypertext
application. There are many combinations of context and user's
actions.
Link-Resolving (LinkResolver) components [from Tompa] are used to solve the above two problems. Some properties of LinkResolver includes:
- Each HyperApp has one or more LinkResolvers.
- LinkResolver resolves a link based on the combination of a user's action and context. User action may refer to things like clicking on a word or drag a word to the trashcan. Context refers to the mode of the application. For example, a web browser mode is concerned with the URL of anchors. A dictionary is concerned with the spelling of the word. Not all LinkResolvers are sensitive to all combinations of action and context.
- Different LinkResolvers may retrieve different links in the same
user's action and context.
- Each LinkResolver resolves one type of link.
- The link retrieved by LinkResolver may not necessarily be a HyperLink. It can be any object.
When the user has done something meaningful, the controller records what he has done into WebGUIAction. HyperApp then broadcasts that to all its LinkResolvers. If a LinkResolver is interested in that action, then it will use the information stored in the action, such as the coordinates of the point just clicked, to try to resolve a link. If it is successful, then the LinkResolver reports the link back to HyperApp. HyperApp then checks if this HyperLink is of interest to itself. If it is, it will access the HyperComponent located by that HyperLink. No matter if the HyperLink is of interest or not, HyperApp will broadcast it to its dependents.
WebClient of NetFish uses three concrete subclasses of LinkResolvers. They are CharResolver, TextResolver, and UrlResolver.
Alternative Designs