[stringtemplate-interest] visualizer mockup

[Gerald Rosenberg]

At 04:13 PM 11/23/2009, Sam Harwell wrote:
>Hi Gerald,
>
>I think you have the wrong idea on what this is. 

Sigh, no, I think you need to reconsider the mockup and re-read what Ter wrote.  Specifically,

"As I mouse over a section generated by a template, it highlights (one at a time) with a box or whatever.  I can collapse output for any  expression/template.  If I hit "get info" key it would pop up a dialog showing the template pattern and the attribute table (an inspector). "

As I read this, it describes is a relatively static post generation inspection of the output with code assist features to show the generative template, describe its signature, and display the corresponding input values.  There is also code (template) folding and a few other editor features implicated.

>The problem template
>coders always run into, regardless of which IDE they use to edit
>templates, is understanding how the output ties to the templates. In
>essence, we're talking about a specialized debugger that operates very
>much unlike other debuggers.

With the caveat that the specialized debugger you are referring to a post-generation inspector, then I largely agree with you.  Although there are procedural aspects involved, Antlr/StringTemplate are basically structure generators.  Better to just produce the structure in full and then facilitate inspection of the generated output, i.e., provide active double-click and infopopup hooks back into the relevant source material.  That way you can easily jump around the structure to see and compare how different parts were generated.  This is what ASTView and the AntlrDT Parser Visualization do.  

Yes, this is not a standard debugger, but then Eclipse (and the others I believe) are not actually IDEs: they are tools platforms.  Much, including the editors and debugging infrastructure, can be jettisoned or re-purposed quite nicely.  

>I'll talk about this in regards to HTML output, but it wouldn't
>necessarily be HTML. Instead of outputting "plain text" from rendering a
>template, it would output an HTML-formatted annotated string. One pane
>could show the text that was output, but if you hover over text in it,
>another pane would show you the template rendering stack at the time
>that text was written along with information about the object(s)
>involved in rendering. 

Yes, each rendered string would be active in the sense that, through the platform, it would logically connect back to the template that created it, its signature, and the values supplied to it.  Should even be able to connect back to the relevant grammar rule and its source text.  

As a comparative example, the ASTView captures the live AST structure and the token stream as active elements.  Click on any node in the AST tree view and the corresponding grammar rule or element is highlighted in the grammar editor.  Click on any token in the token stream list view and the exact source text for that token is highlighted in its own text editor window.  

Similarly, the Parser visualization captures the entire event sequence of the executed parser, including decision points, LTs, backtracking, and grammar element and source text offsets.  Hover over any visualization node (event), and an infopop identifies the rule, source text, decision state, etc.  Double click on the node and, depending on type, the corresponding rule or element is highlighted or the corresponding token of source text is highlighted, all in appropriately typed windows.

ASTView and the AntlrDT Parser Visualization were designed to be active debugging tools.  They are not too dissimilar to what I think Ter is looking for.  (Just need to encourage/convince him to start from a strong tools platform.)

>There's no real requirement that this be tied to a particular IDE, and
>I'm not convinced an IDE has much to offer regarding this particular
>feature.

You misunderestimate!  With the debug visualization tied directly to the editor(s), it becomes very easy to consider and correct errors, or at least to quickly make and test corrections.  Necessary?  No.  But the productivity is compelling.

Or, is there an underlying sentiment not to be tied to a third-party platform like Eclipse, NetBeans, etc.  Cannot reasonably avoid it -- even AntlrWorks is built on a third-party platform.  Might as well pick the platform that gets you the furthest down the road.  After all, isn't that what we are doing by using Antlr and StringTemplate?

Best,
Gerald