The idea of implementing client-side data binding is something that really
appeals to me, and I think it can really spur innovation in the world of
tech. So, I wanted to give each terminal window the ability to have its
own arbitrarily sophisticated environment that could be persisted between
page loads.
In normal command line mode, everything is really just treated like a
string that must be interpreted based upon the particular command that has
been invoked.
Try doing:
$ echo 1 2 3 4 5
And then:
$ echo "1 2 3 4 5"
...there's really no difference between the two.
But then you can interact with the terminal's environment object by running
the "eval" command as such:
$ eval one=1
This is much different than saying:
$ eval two="2"
After running both of these commands, you can do this:
$ env
...in order to see a nicely formatted representation of the environment in
which you are running. You will see that there is indeed a fundamental
difference in terms of the internal representations of the variables,
"one" and "two".
Now the thing that really makes this stand apart from, for example, a bash
environment, is that you can create arbitrarily sophisticated object
trees.
One way to create an object is by using variable names that you've already
declared like this:
$ eval myobj={one,two}
This will create a JSON object with the keys set to "one" and "two", and
the values set to the values that you've given them.
But to start having real fun, you can do something like this:
$ eval myobj.childobj={}
$ eval myobj.childobj.which=true
Then you can also make pure arrays with this kind of notation:
$ eval arr=[1, "two", myobj, 4, false]
Okay, writing all of these eval's seems pretty tedious, no? How about
running the command:
$ evalon
...in order to make the initial "eval" implicit. And the commands will
look like this:
> myobituary = "Goodbye cruel world"
You can exit from this mode just by pressing ctrl+c, or simply by typing a
period into the prompt and pressing enter.
My motivation for all of the above is simply to allow for easy typed data
binding between remote machines, whether the machines are clients or
servers. That is, you can define a data structure in your browser, and then
have it unambiguously persisted on the serverside, or even in other
clientside desktops.
I so far have done some work in terms of keeping these JSON objects on the
server as python dict types, and then being able to remotely manipulate
these objects via xhr POST requests. This will allow for the rapid
development of application specific data structures within the browser,
and then deploying these same structures with just a couple of key strokes
from the browser's own terminal.
Give it a try!
On Wednesday, January 22, 2014 8:28:16 AM UTC-5, Dennis Kane wrote:
>
> It has been kind of an obsession for me to create the kind of end-user
> experience that will really allow node to start actually being put to use.
> I've spent pretty much an entire year of full time coding getting this
> thing ready for prime time. The only caveat is that you need a Chrome
> browser, as it crucially depends on the filesystem API. I won't get into
> the details of how to user it. For now, just go there and start clicking
> around. As people show interest, I'll start giving instructions.
>
> Where is "there"?
>
> HERE --> http://urdesk.net
>
> urdesk means: "yoUR DESK" and "Uniform Resource DESK".
>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
