Tag: FlowSharp

Building a Web-Based Diagramming App with SVG and Javascript

I’ve been wanting to learn about SVG for a while now, and there are certainly any number of helpful websites on creating SVG drawings and animations. But I didn’t want to learn how to create static (or even animated) SVG drawings, I wanted to learn how to use SVG dynamically:

  • Create, modify, and remove SVG elements dynamically.
    Hook events for moving elements around, changing their attributes, etc.
    Save and restore a drawing.
    Discover quirks and how to work around them.

That’s what this article is about — it will only teach you SVG and Javascript in so far as to achieve the goals outlined above. However, what it will teach you is how to create dynamic SVG drawings, and what better way to do this than to actually create a simple drawing program. Then again, I learned a lot about both SVG and modern Javascript writing this article.

Read the rest of the article on Code Project!

Code is also on GitHub.

 

FlowSharpCode, continued…

fsc2.png

A simple example, but the “problem” is that the three Drakon shapes (begin loop, output, and end loop) each still have individual C# code-behind in each shape.  For example, the begin loop has the code-behind:

 var n in Enumerable.Range(1, 10)

My original idea was that the Drakon shape description should not define the language-specific syntax, instead that should be implemented by the developer in the code-behind.

In practice (and I’ve written a complex application in FlowSharpCode, so I know) it becomes unwieldy to deal with one-liner code behind, the result of which is that I tend not to use Drakon shapes, but that results in nothing better than a meaningless box with some code in it.

I’m also reluctant to put the code in the shape label (though this is supported) as again we’re now dealing with language specific syntax.

I’m also reluctant to create a meta-language for Drakon shapes, for example, something that could interpret:

n = 1..10

into C#, Python, whatever.  What if the developer wants to write:

Count from 1 to 10

So, what I’m considering is letting the developer create the Domain Specific Language (DSL) so that they can expressively communicate the semantics of a Drakon shape and also provide the rules for how the semantics is parsed, ideally in an intermediate language (IL), for example, something that expresses a for loop, a method call, whatever.

The advantage to this is that the developer can create whatever DSL they like to work in, the IL glues it together into the concrete language.

Two things happen then:

  1. The DSL is interchangeable.  Any IL can be super-composed into your DSL choice.
  2. The IL is language independent, so it can be de-composed into language specific syntax.

Item #2 of course imposes some significant limitations — what if a language doesn’t support classes, or interfaces, or yield operator, or whatever?  I’m not particularly too concerned about that as a language-independent DSL/IL is more of a curiosity piece, as it becomes rapidly untenable when your code starts calling language-framework-platform dependencies.

However, I’d love to hear my readers thoughts on this DSL/IL concept I’m considering.

 

 

FlowSharpCode Gets DRAKON Shapes

drakon1.png

I’ve added some select DRAKON shapes for creating flowcharts.  The Python code in the lower right editor is generated from the flowchart, and the output from the run is shown on the left.

PyLint is also now integrated into FlowSharpCode’s PythonCompilerService.  This really improves the development process as many syntactical errors are detected before even running the code.

Also, the code generator creates an execution tree which independent of the language syntax, which means that support for other languages is easily added.  Now granted, the code itself in each of the DRAKON shapes is Python code, but I have some ideas of how to make that code agnostic as well.

Adding Services to FlowSharp

overview.png

I’ve been reworking FlowSharp into a “Service Oriented Architecture.”  As the above overview diagram illustrates, there are now three major service blocks:

  1. Docking services – The toolbar and property grid are now dockable, and canvases are treated as dockable documents, so you can have multiple documents in one application.
  2. The various controllers and functions of FlowSharp have been converted to services (see below)
  3. As a result, I’ve been able to add the “shapes as code” in the FlowSharpCode project that I wrote about earlier.  The beauty of this is, adding the FlowSharpCode services “simply” requires defining the services in modules.xml and the additional shapes in plugins.txt.

The architecture relies on The Clifton Method discussed previously.

Here’s a full blown gloriosky architecture diagram:

architecture-small.png

Find FlowSharp on GitHub!

At the time of this writing, there’s still a few critical bugs to update the Code Project article, but I hope to get them resolved soon!

V.A.P.O.R.ware – Visual Assisted Programming / Organizational Representation

vapor2.png

Actually the name of the application is FlowSharpCode, but VAPORware sounds more fun!

Article here.

Excerpt:

This is purely a concept piece.  It’s intended to either inspire or cause an eye rolling “what a crazy idea” reaction.  It is crazy, in my opinion, but in a sense it’s crazy because in my limited use cases so far, it works.  And because it’s so crazy, the majority of this article will not be written, it’ll be screenshots of the application in use. The problem with this approach is that it ends up sort of looking like a PowerPoint presentation, which is hard to avoid!