[SrcML] ViewPlatform improvements

[Frank R. <fra...@un...>]

Attention: Long posting ahead. If you don't want to read it all at least
read the last paragraph please.

So here's another shot at how the current ViewPlatform could be
improved:

The distinction of our three main objectives is in principal very
powerful for creating new views which are derived from existing ones and
only change little aspects. However I don't think the additional
learning overhead to understand this system really justifies that.

What do you think of reducing the complexity by reducing view plugins to
a single class with a method for each tag? These methods will be
responsilbe for the ordering of the child nodes, the generated strings
and the generated whitespace.

A new plugin could still be derived from an existing and only some
methods could be overwritten. The downside of course is that for
changing only whitespace the whole method would have to be rewritten.
But as I mentioned above I think it's far easier to copy/paste that
method and modify the parts you want changed than understand the current
split into the various plugins, the indexing scheme and its
implications. Not even mentioning that we will not see too many derived
plugins anyways.

There's one more problem I can see with this approach. Interacting with
the generation mechanism would be more difficult. The current Iterator
would be gone, as each method is itself responsible for deciding which
nodes will be printed next and this will not be calculated in advance
(again this will be easier to understand I think). So hooking into this
process from some other code gets a bit trickier. Imagine the HTML view
which wants to use the normal view plugin and surround certain nodes'
output with the corresponding HTML tags.
An idea how to solve this would be denying the view plugin access to the
actual output plugin used, but providing it with an event system, so
that the plugin can send events. Those events will be caught by the
base Plugin class which forwards them appropriately to the output
plugin. On the other hand any other code fragment interested to interact
with the generation can register its own listeners.

Here's an example of how I'd imagine a view plugin to look like then
(minus the excess comments to stay realistic ;)

public void _handleNode(de.srcml.dom.Class f_class)
{
    // the handleNodes method would be a helper method defined in the
    // Plugin baseclass which takes a List of nodes for which events
    // will be generated that cause the baseclass to call the
    // corresponding methods of the plugin.
    // The f_class parameter is supplied, so that each event can be
    // marked with the node it was sent from.
    handleNodes(f_class, f_class.getCommentAndJavadocNodes());

    // same as above
    handleNodes(f_class.getAnnotationNodes());

    // same as the above, just for a single node
    handleNode(f_class.getModifiersNode());

    // here's an actual output. As mentioned above this will not be sent
    // to the output plugin directly, but results in an event (four
    // types of events possible as far as I can see: strings, inner whitespace
    // w/o linebreaks, linebreaks and indents)
    if (f_class.getModifiersNode() == null) outputWS(" ");
    outputString("class");
    outputWS(" ");
    outputString(f_class.getAttribute(de.srcml.dom.Class.ATTR_NAME));

    handleNode(f_class.getParameterizationNode());

    if (f_class.getBaseclassesNode() != null) {
        outputWS(" ");
        handleNode(f_class.getBaseclassesNode());
    }

    if (f_class.getInterfacesNode() != null) {
        outputWS(" ");
        handleNode(f_class.getInterfacesNode());
    }

    // a newline should get it's own event (should be simple to add line
    // numbers f.ex.)
    outputNewline(f_class);

    // Indents are different from simple spaces between identifiers, but
    // it's not absolutely neccessary to handle these separately
    //outputIndent(f_class);
    // (of course you don't really want to indent the class' block. but
    // a call like this would be due in the method handling
    // de.srcml.dom.Block f.ex.)

    handleNode(f_class.getBlockNode());
}

This code is of course very similar to the existing code, but unifies
the content of all 3 methods: getPermutation, getString and getBefore in
a way that everyone can far more easily imagine how the output will look
like.

A final point of consideration would be whether we want to allow
registered listeners to turn down an event. This means fixing the call
order to the inverse registration order and the called method returning
false meaning that the event will be thrown away. I can imagine this to
be useful f.ex. when wanting to print code without comments, or only to
a certain detail level (like no expressions) etc.






Now that the practical is basically over I liked to know who is still
interested in working on SrcML and discussing such issues. I'm not
writing these mails because I got nothing better to do, but to provoke
constructive feedback. However if nobody's interested in that I could
save the effort of trying to keep you updated on the current design
questions and stop giving you the chance to influence the project.

-- 
Raiser, Frank
Student @ University of Ulm (www.uni-ulm.de)

Should array indices start at 0 or 1?
My compromise of 0.5 was rejected without, I thought, proper consideration.
(Stan Kelly-Bootle)