Interface for Visualization

[fub-frank]

To make it work with the ServiceLoader used in our controllers, the visualisation of TokenStream, AST and TAC needs an interface. Three interfaces should be defined (one for token stream visualization, one for ast visualization and one for tac visualization).

I hereby propose the following interfaces:

public interface TokenStreamVisualization {
    /**
     * Visualize the token stream
     */
    public void visualizeTokenStream(Lexer lexer);
}

public interface ASTVisualization {
    /**
     * Visualize the ast
     */
    public void visualizeAST(AST ast);
}

public interface TACVisualization {
    /**
     * Visualize the tac
     */
    public void visualizeTAC(List<Quadruple> tac);
}

// edit: updated TACVisualization interface

[Tkrauss]

I already talked to @flofreud about this feature. According to him, the visualization depends on the specific implementation, not on the interface. This assumption would imply, that there is no need for any common interface design. Correct me if my premise was wrong. And generally, do you mind to discuss the proposed design and commit just the final version, when -- or if ;) -- there's a common agreement of all participants?

[flofreud]

@Tkrauss I have to correct myself. There seems to be a misunderstanding which i have reproduced. The project lead would like to have visualization only depending onto the interfaces which should be replaceable by their counterparts in the other group.

[Tkrauss]

Ah okay, under those circumstances a common interface makes sense indeed;). But i think it's important to think about the intercompatibility. Let's say, FUC decides to use swing and we decide to use some fancy javaFX stuff. In that case, it's impossible to mix the components. Maybe some more tailored approach is appropriate. For example, if both groups agree to use swing, we can return a JPane or something similar from each method.

[flofreud]

Hopefully I got it right now but I think that Max told me the following:

It has to be interchangeable to the extend, that the visualization of one controller (eg AST) still works if the other implementation (eg parser) is used.

So that the visualization works against the same model. Sorry to cause more confusion.

On Thu, May 16, 2013 at 10:17 PM, Tkrauss notifications@github.com wrote:

Ah okay, under those circumstances a common interface makes sense indeed;). But i think it's important to think about the intercompatibility. Let's say, FUC decides to use swing and we decide to use some fancy javaFX stuff. In that case, it's impossible to mix the components. Maybe some more tailored approach is appropriate. For example, if both groups agree to use swing, we can return a JPane or something similar from each method.

— Reply to this email directly or view it on GitHubhttps://github.com/swp-uebersetzerbau-ss13/common/issues/22#issuecomment-18026284 .

[fub-frank]

Let's say, FUC decides to use swing and we decide to use some fancy javaFX stuff. In that case, it's impossible to mix the components.

This should not be a problem. The Implementation of the interface needs to deliver the complete Visualisation. So you do not return a JPanel or something similar but you have to start up your complete gui.

Maybe some more tailored approach is appropriate. For example, if both groups agree to use swing, we can return a JPane or something similar from each method.

Idea behind the interfaces is to be completely independent from the visualization choice. E.g. you can decide to use console output by just printing to stdout / logger facility or you can use a gui to display your visualization by starting a Swing Application or JFX Application.

This is why there is no return type in the interface above.

I hope this clears it up.

[Tkrauss]

In my opinion, finding the right interface is more likely to find the greatest common divisor. We thought about implementing a minimalistic ide, where the gcd would be a JPane. If you plan sth completely different, it's okay and i agree on this. But if you want to develop a swing-based application, we should change it imho. If your roadmap for the visualization is not sure yet, we can leave the concrete interface definition open till you're done.

[fub-frank]

FUC group decided to build a gui in one of the next milestones. But this is not concrete at the moment. I think your Mini-IDE should be independent of those interfaces above as it covers more than just one of those interfaces.

Maybe it is an idea to develop all of your visualization tools as a JPane. If the above Interfaces are called, the JPane's will be put into a JFrame open as a stand alone swing gui. Your Mini-IDE can then reuse these JPane's and display all of them in a single JFrame. To do this, the Mini-IDE does not need to follow the above interfaces. Something similar to this:

class ... implements ASTVisualization {
    public void visualizeAST(AST ast) {
        JFrame frame = new JFrame();
        frame.setContentPane(new Mini-IDE-JPanel-For-AST());
    }
}

class Mini-IDE {
    public static void main(String[] args) {
        createSuperDuperGUI(new Mini-IDE-JPanel-For-AST());
        createSuperDuperGUI(new Mini-IDE-JPanel-For-TAC());
        createSuperDuperGUI(new Mini-IDE-JPanel-For-Token());
        ...
    }
}

Without regarding the idea above, FUC Group needs to be independent from a specific return type as some of our visualization implementations will write to console stdout or create xml files. Those implementations (of course) can not return a JPanel.

We also want to be able to enable several different visualizations at the same time (e.g. enabling TAC Visualization as Triples and as Quadruples at the same time).

[Tkrauss]

It's quite easy to show that our approach is integrable in this design, sure. So, if you really want to create xml and console output ( whose can easily been piped to some TextPanel btw), we have to take this solution. I think, if nobody has additional remarks, we can close this issue at the 28.05. In that case, everyone agree on the greatest common divisor being 1;) --- which is hardly helpful, but valid.

[fub-frank]

Is it more useful to have distinct interfaces for GUI Visualization and Console Visualization?

example:

// marker interface
public interface TACViusalization {}

// console interface
public interface TACConsoleVisualization extends TACVisualization {
    public void visualizeTAC(List<Quadruple> tac);
}

// gui interface
public interface TACGUIVisualization extends TACVisualization {
    public JPanel visualizeTAC(List<Quadruple> tac);
}

or similar.

Another idea is to put both methods (visualizeGUI and visualizeConsole) in the same interface and mark them optional. You then need to implement at least one of them and throw a UnsupportedOperationException for the other one. But i think this is bad design.

[fub-frank]

Discussion with tutors leaded to the following result:

Visualization has to work with all Components (Lexer, Parser, ...). Therefore visualisation has to use the common interfaces to access its data.

Though visualisation components (like AST Visualisation, TAC Visualisation etc) does not need to be interchangable between both visualisations. Therefore no common interface is needed to stick to for visualisation components.