Visualizing a directory tree and Browsing HTML files   Summary This grammar performs a recursive scan of a directory of your filesystem for HTML files and represents the directory tree as a graph. Afterwards, it starts up an HTML browser to inspect the files that have been found. The files already visited are being marked in the graph. This example demonstrates how you can access system resources like the file system using Java method calls in graph rules. It also shows how you can control an external Java application (here: the browser) by graph transformation rules.

Screenshots

The following image shows the rule initDir being applied to the start graph of the grammar "HTML Browser". The rule has launched a dialog asking for the directory to browse.

After application of rule initDir has finished, the Directory node will show the name of the directory to be scanned (this attribute is actually set to an instance of the custom class Entry, providing the methods we need for scanning later on), the number of entries that have been found is 0 initially, and the expanded attribute is set to false, indicating that we are not yet done scanning this directory.

Next, rule showDir is applied as long as an unexpanded Directory node is found in the graph, and it creates a new Directory node for each subdirectory encountered.  Afterwards, the state graph may look like this; note that all the expanded attributes are true now, and that the entries value denotes the number of subdirectories.

In a second pass, which is prepared by the rule prepare2ndPass, each of the directories is scanned for files with suffixes ".html" or ".htm", and a HtmlFile node is created for each one found. This is accomplished by the rule showFile, which works in the same way as showDir. In our case, the rule has found 1 HTML file in the "/home/tfs/gragra/AGG/WWW/examples_V100b/ShortestPath" directory and 1 in the "/home/tfs/gragra/AGG/WWW/examples_V100b/Shipping".

Now we are using rule openBrowser to pop up a simple HTML file viewer, implemented by the Java class Browser (the actual implementation of the browser is done in the class HtmlPane, which was taken from the MetalworksHelp class of the Swing examples from SUN). The negative application condition ensures that only one instance of the browser will be created.

Automatic execution of the example will stop at this point, since the rule viewPage is located below the stop mark, and none of the other rules is applicable any more. We proceed by selecting rule viewPage and then choosing Transform->Step: The rule will select a HtmlFile node and display it in the browser represented by the Browser node. The chosen HtmlFile node is marked as visited, and the negative application condition of viewPage ensures that it will not be visited again. If you want to inspect a particular file, you can define a partial match to do so: Pop up the context menu of the HtmlFile node in the left-hand rule side and select Map, then click on the HtmlFile node in the state graph you want to be shown. Selecting Transform->Step will complete the given match before applying the rule.

Just in case that you are wondering why there is a semicolon in the expression br;setPage(...) on the right-hand side of rule viewPage: This is a special notation introduced by the attribute handler. Basically, it is to replace the "." (dot) notation of method invocation, with the difference that the return value of the invoked method is ignored and the object itself (br, in our case) is returned instead. The semicolon notation is an undocumented feature because we don't like to alter Java syntax and semantics. Note that you can always avoid using the semicolon by writing wrapper methods returning the desired object. However, it seems convenient to use the semicolon.

Revision: