Package smacs.gui.service.simple

Explorer Simple Viewer Service.

See:
Description

Class Summary

SimpleNodeDecorator	xngr XDecorator implementation.
SqlTableReferenceAction	xngr XAction implementation.
SqlTableReferenceDecorator	xngr XDecorator implementation.
SqlTableReferenceService	xngr XService implementation.

Package smacs.gui.service.simple Description

Explorer Simple Viewer Service.

Large parts are easy to get - have a Service file that contains two methods that map XElement types to an XAction[] list (the rightclick menu) and map XElement to a Decorator instances (telling the icon and tooltip for an Element in the explorer document view).

Now, the question goes - where do we get the substructuring of presenting a deeply nested tree as is with an SQL parse tree? The answer is in smacs.xngr.browser.explorer.ElementNode :

{
  // Parses the document and adds all the elements to the document node.
  private void read(ExchangerElement parent):
    List list = parent.elements()
    Iterator i = list.iterator()
    while i.hasNext() :
      ExchangerElement element = (ExchangerElement) i.next();
      if manager.getHandler(element.getType()) != null :
	this.add(new ElementNode(element, manager));
      else:
	read(element) // recurse!
}

Seen it? The element node will only be added to the GUI view iff there is a map of the element type to a handler instance. Otherwise the subtree is searched (or so it says). So here is the real question: where the heck can one modify the getHandler() result?

First of all, the "manager" up there is a browser.service.ServiceManager, and it contains a Hashtable&; key:XElementType,value:ElementTypeHandler&;, whereon the getHandler() function uses really just a lookup. Now the mysterious ElementTypeHandler is an association to a service and also the decoration and action that we do already now. Now here is the actual embaressing part:

service is of ExchangerService! Hardcoded, not an XService reference!

So effectivly there is a method ServiceManager.add(ExchangerService) that will call for ExchangerService.getElementTypeProperties() that returns a Vector&; ElementTypeProperties&; and the ElementTypeProperties is converted to a plain XElementType (via getLocalname and getNamespace) being the pushed down associating the XElementType to our ExchangerService!

In short: XService is missing a method getElementTypeProperties() returning a something that is a representative of an XElementType thereby associating an XElementType to an XService. It's missing.

Is it?

Let us have a look at ExchangerService - its constructor has three arguments and the second is of type ServiceProperties. And the call of ExchangerService.getElementTypeProperties() will actually call ServiceProperties.getElementTypes() returning... a List&; ElementType- Properties&;. So, where can we hand over those ServiceProperties?

Well, there is nothing in the examples, instead we see that the ExchangerService instance is created by ServiceFactory.FACTORY .createService(props) in browser.Main.java where props is of type ConfigurationProperties representing the xngr.xml config file.

Now how?

The ServiceFactory.FACTORY.createService(props) will actually get is list of ElementTypes from document.getElementTypes() returning a ServiceDocument.ElementType[] array. And that array is initialized by the "&; element-type&;" entries. And that's all? Well, it can't be since it does not work.

The real reason, it does work but you have to explicitly unload and reload the service module. The explorer view will cache the element- type information in the xngr.xml file as a permanent configuration. So whenever you change the service.xml script you need to reregister.

That's all?

No, it is still not completely satisfying - the explorer view will somehow show the node list hiararchically but actually sorted in alphabetic order rather than saved order. So where the hell can I shut that down.