12 Design Principles of XVG

The scale of the SVG design surface can be adjusted as desired or made full screen


crude sketch showing demarcation points of XVG mouse click handling

Just run, baby!

XVG is a simple, desktop-oriented SPA that allows end users to draw Islamic geometric patterns via point-and-click usage of a mouse.

It has the look-and-feel of a native Windows 7-ish application, which ought to appeal to graphic designers familiar with the classic MS way of doing things.

The idea is you don’t want an end user to have spend too much time trying to figure how to use XVG, while making some of the SVG design innovations of the tool be as natural and familiar as possible to Windows users.

From an open source programming perspective, I also want XVG to be easy for anyone — especially newcomers to JS who are learning about Islamic geometry — to easily extend the app to suit their particular needs.

I also want XVG to be protected from malicious hacking.

Finally, I reckon most programmers would rather not have to figure out some more or less over sophisticated or cryptically terse or overly abstract or otherwise confusing piece of (uncommented) code.

For these reasons, I have decided to adhere to the following 12 application design and coding rules:

    1.  No connection to the Internet, except in the embedded SVG workspace in the main layout html document, and at the top of the “dispatcher” JS module (which is loaded by the html doc), where it is required for subsequent SVG DOM manipulation to work*
    2. No CSS preprocessors
    3. Emphasis on combining structured analysis and design of the problem domain with early prototyping and subsequent refactoring
    4. Usage of latest ECMAScript functionality allowed, but only where there is a compelling technical rationale to do so — otherwise, plain JS is encouraged
    5. Optimized to Blink browser engines (Chrome, Edge, Opera, et al), due to a number of technical reasons (chief among them the availability of WebSQL as a storage engine)
    6. Usage of nested callbacks will be minimized and promises written as async/await functions
    7. Fancy and or showoff JS abstractions and/or patterns are to be avoided in order to emphasize code readability and maintainability
    8. Reliance on a custom dispatcher to funnel SVG and HTML event handling into 2 separate JS function files**
    9. XVG is almost stateless, in order to reduce complexity — thus, no “undo” for e.g. — except when it comes to keeping track of a limited number of event types (see Point 8)
    10. Persistence of user-created SVG designs is achieved via direct SQL statements sent to the browser’s WebSQL db. Since XVG does not expose its DB to Internet end uers, there is no needed for the tedious extra work that must be done to protect against SQL injections for apps that do.
    11. No frameworks, such as Vue, Angular etc
    12. No third-party JS libraries, or node.js

My hope is that adherence to these principles will allow me to efficiently develop XVG.

* the only connections to ze miracle of the Internet are here

… (~.js)

const svgNS = namespaceFunction();
function namespaceFunction() {
… (~.html)
note: the Unicode Right Double Quotation Mark weirdness you see at the end of the return statement is caused by the annoying WP HTML processor.
I will not be using the native JS module system, as this requires a local server.  I do not wish burden the end user with having to set up one, and want XVG to be a self contained app that does not need to access any external resources (except as indicated above).
However, I do need to modularize my code to make it easier to understand, maintain and extend.
 Since I cannot use type=”module” and import/export of functions dynamically (due to my decision not to use a local server), I will rely on the HTML <src> tag with a defer attribute to load XVG’s JS files in sequence.
Per MDN…

deferThis Boolean attribute is set to indicate to a browser that the script is meant to be executed after the document has been parsed, but before firing DOMContentLoaded.

Scripts with the defer attribute will prevent the DOMContentLoaded event from firing until the script has loaded and finished evaluating.


** in and of itself, that is not difficult.  the trick is how to distinguish SVG freehand draw events (where the user drags the mouse to create a line) from SCG “static draw” events, where the user clicks on two markers in succession to create a line connecting the two. further complicating things is what happens if the user interrupts a static draw midstream. How to efficiently construct a dispatcher is explained very clearly and simply here.

#  #  #