new Autogram().nameIs('tmpA')
.itIsA('div')
.make().its('className','divish').its('left','0px').its('height','300px')
.link().its('height').to(Autogram2)
.constrain('width').between('5','50').ifViolatedTrigger('function()')
.drawOn('document.body')
I also created a function called "traversion", a portmanteau of traverse and conversion, to have a single "super function" handling all of the mapping between the DOM and my objects. In my code there was a lot of repetitive dialing in and out of nested objects and arrays inside my "_parse" functions.
However, I end up sort of discarding both ideas. The first because in practice it actually isn't any less work than writing a Blueprint JSON spec for an Autogram and also requires creating both/either a new function for every new aspect that needs to be modified and having a variety of handling routines depending on the number of parameters for certain functions.
The second because the more I worked to generalize my parsing routine in order to save on work and writing new functions I ended up over-generalizing and find myself with a clearer separation between my wrapper object and the underlying DOM. This becomes a problem because now there is more work necessary translating between the two systems. This led to my next attempt.
Third attempt
The third attempt began with a focus on how to allow specifying more complex numerical relationships between object value dependencies.
I started off by creating what I called "equation values" in order to create "dynamic equations"; any property can be set to an equation that depends on other values in order to make a non-hierarchical scene graph based around "anchor points". The idea is you layout your entire app around 'base values' that you use to organize and structure all elements. If there is a screen resize event all of the dependent objects will resize appropriately based on their individual constraints. This was meant to solve the new problem introduced by smartphones and tablets of accommodating many different screen sizes without needing to design different apps/layouts.
To avoid dragging the reader through endless technical investigations, false starts, resets, etc. I'll sum up by saying that exploring this problem space led me to examine the foundational concepts of what programming actually is and the different programming models or paradigms that exist such as dataflow, data-driven, functional, etc.
I ended up creating an assembly language-esque structure where each line could be hooked into.* The good? It was straightforward, declarative syntax. The problem? like assembly language, it took a lot of statements to accomplish simple things. Even more, it was very awkward to specify branching and conditional statements. Writing an entire scene graph this way was anything but direct and intuitive. This led me full-circle to what I mentioned up above, creating a DSL. However, instead of creating YAJSS-- and to solve the "mapping issue" --I realized I could just create a subset of JavaScript, like JSON, that simply worked a bit differently under the hood for my "dynamic equations". So, once again, I got to work experimenting with writing a simple equation parser.
*This in turn led me to discover asm.js and Web Assembly standard that are still a work-in-progress.
However, life and the tech industry were not sitting still and it was at this point that it became necessary to take a step away and a step back and leave a thumb tack in my coding journey until a later date.
note - I will also mention briefly that among all these revisions I also took the time to dig into the world of NoSQL databases and found CouchDB to be most in line with my ideas. It was around this time that the creator of CouchDB, Damien Katz, left the project to do other things and this caused a bit of drama. Unfortunately, what I wanted to do at the time-- create a database for every user that signed up --wasn't possible at the time without using another server. I created a StackOverflow entry here discussing the issue. I also left a thumb tack at this point to learn Erlang, the language CouchDB is written in, so I could modify it in the direction I think it should go. I checked back some years later and a 'couch_peruser' setting was finally added that allowed the feature I was going to add myself.
Next.