On Sat, 2012-02-11 at 15:09 +0100, Axel Kittenberger wrote:
> > Yes, that's probably a relatively good meantime solution - however,
> > I'll probably have to write something ugly to access the DOM from
> > node...
>
> Without knowing your App in detail you don't need to. The tendancy is
> to write the server-end in node only caring for the things you need
> the server for, and the frontend in Browser Javascript which does all
> the markup. Then have both communicate with each other via JSON. You
> should not need to access some DOM specifics from node. Of course you
> can easily do your JSON-based call to do that, but it would be far
> more elegant to have the communication on a more abstract level.
> Instead of for example server saying "write headline, make it bold,
> and red, and write warning", you just send "{cmd: warning}" and have
> the browser client do the markup.
>
This particular subject and Node.js, is the primary reason why I decided
to learn Javascript a few months ago.
I wish I had the javascript experience to write this right now!
One of my favorite scripting languages is Tcl/Tk, so I thought about
using Tk to do the GUI stuff.
But then using Tk would NOT work very well in a Web environment, so I've
considered writing some Tcl socket logic to drive the Web browser from
the server.
Then I tripped over a Google Talks session with Ryan Dahl, about Node,
maybe two months ago. So I'm behind you guys here in more than one way.
With the concept of Node, and the latest additions to HTML5 and CSS3
this GUI complexity can be done away with.
The current state of GUI development is chaotic at best.
What Ryan did on the Server Side, needs to be done to the GUI now.
In large enterprise applications a large percentage of programming
effort goes into the GUI, it is ridiculous.
I've learned that GUI development in many environments, is overly
complicated.
The reason is because GUI's are just hard to get right, and their are
too many opinions of how to do it,
too many various libraries for GUI stuff, many of them reinvented to try
to do it better.
Like, hey lets solve all the worlds GUI problems, and thats is the main
problem.
It Is Complicated! However, over the last decade or so, we've been
watching the Browser evolution,
and the browser guys have the most experience with GUI failures, and you
don't want to relive all their agony.
Therefore it is the browser guys that you should follow and using the
browser to present your GUI is the path of least resistance.
The browser guys have done all the heavy lifting for you already.
Believe me, you don't want to reinvent all of that GUI stuff that they
have done, failed and redone, many times over again and again, for many
years.
It will take you years to get where they are today!
Jann,
I think you are on to something when you say you want to do as much as
possible in Node.
But all that ugly DOM stuff you mentioned, that must stay in the DOM,
don't put any of that in Node on the server.
Do something that is absolutely awesome, try to imagine this:
Keep in mind that this is all theory, and not proven, but I believe it
is doable.
It will basically turn the current GUI concept on its head, where it
should be, kind of like it was many years ago.
Instead of having the DOM control the server, have the server drive the
DOM.
Simply by sending/receiving JSON with Asynchronous, bidirectional,
Web-socket I/O, much like what Alex said.
This can work as long as the JSON data contains only meta-data, no
actual DOM syntax, very small,
and the communication is Asynchronous, bidirectional, Web-socket I/O.
To break it down a little more, here the term "you" refers to Node on
the server.
So, from Node (on the server) you tell the DOM (browser) what to do,
using only meta-data (no DOM syntax) in a JSON data format.
Like Initialize the DOM/GUI, update the data buffer (Text inputs),
change an element, Callbacks to Wait for a DOM event,
sending and receiving, to/from the DOM nothing but JSON data to describe
exactly what you are asking the DOM to do,
or ask the DOM to tell you about events, get data enter by the user edit
and send it back to the DOM. So it will be Node on the server telling
the DOM what to do,
and Node on the server asking the DOM for specific information or data.
Because you tell the DOM what events you want to know about, and
elements you want to manage.
Application developers can get out of the fashion business,
fashion being colors, fonts and graphics, the team that is working on
the DOM can do whatever they want with css and html, as long as they
support your Send/Receive requests.
I think the cool thing about something like Node is you can use this
same Webapp theory to build a Desktop apps or maybe even a mobile apps.
Using the XULRunner or Chromeless concept your desktop app can be
written in %100 javascript, using HTML and css initially.
If Chromeless doesn't work, fork a copy of an make it work, chromeless
its probably closest to the mark, as XULrunner requires more than pure
HTML.
The an application starts up, during initialization it can start it's
own Node http server, underneath, on the same box, laptop, desktop, or
whatever.
So you end up with a %100 web based, desktop app. Then when ever you
want, you can move the Node http server, and application part off the
desktop and
on to a server, from desktop to instant multiuser (Client/Server) Web
style application.
If this doesn't make sense, they try to forget everything you know about
application programming, and read it again.
For example: to break it down even more:
For meta-data storage use something like Sqlite or Mongo or whatever,
just some storage with a small foot print, kept anywhere as long as
(Node) has access to it.
Then I envision several mainstream functions will be written using Node
on the Server.
Then similar or complimenting functions are to be written for the DOM
side for all of this to work.
Examples of the Server side could be something like the following:
DomInit:
This will create a new JSON object containing the meta-data for elements
on a page, and the ID's or name's of all DOM events the server whats to
know about.
So you can have many events occur on the DOM side that don't concern the
Server side at all.
When a "DomInit" JSON object is sent to the DOM, then javascript on the
DOM should remove any/all existing elements from a previous DomInit,
before creating new elements found in the JSON object.
DomShutdown:
Send JSON to DOM instructions to Shutdown, note:In this case the end
user may only see a parting message,
like "later dude, come back soon" or "Session ended, Connect CPU=3,
Elapsed time=2,375 seconds"
DomHide:
Send JSON to DOM, instructions to Hide everything, all DOM elements
including the Dom itself.
DomUnhide:
Send JSON to DOM, instructions to Unhide everything.
DomGetnextPage:
Send/Receives nothing, Gets a new meta-data from storage, based on an ID
or Name.
DomOpen:
Send/Receives nothing, Opens database or object that contains all your
DOM meta-data.
DomReadElements:
What you would receive from the DOM (browser) would be JSON data
describing the DOM,
all elements that have a data property and each elements data value, the
ID or name of the last DOM event that occurred,
like element.clicked or window.closed, and so on.
DomWriteElements:
Send JSON to DOM, the data and property values of all DOM elements that
have a data property.
For example: same stuff received from DomReadElements, only on the
server you've modified some properties, added or removed some elements.
So DomWriteElements sends this back to the DOM where the DOM javascript
processes it, applying the changes.
Instead of the last event as in DomReadElements, here we want to send
the ID's or name's of all DOM events the server whats to be informed of.
So you can have many events occur on the DOM side that don't concern the
Server side at all.
DomOpenWindow:
Send JSON to DOM, instructions to open a new window.
DomCloseWindow:
Send JSON to DOM, instructions to close a new window.
Their are many more functions, but you get the basic idea,
so you could imagine many others to do more specific things to the DOM.
Keep in mind the only data going through the sockets is JSON, no actual
DOM syntax.
Another issue is simplicity, it must simple and easy to understand.
A minimal set of functions to put you GUI on the browser, for example:
Two functions needed at start:
DomOpen("some_database_name");
DomOpenWindow(passing Some Window geometry, returning some
Window ID);
Three functions to put your GUI on the browser:
DomGetnextPage(somePageName); // returns a JSON-DOM object as
meta-data is found in the database.
DomInit(JSON-DOM); // Send {DomInit: "JSON-DOM"} to the DOM,
specifying the Window-ID.
DomReadElements(returning an event) // based on the list of
events in the JSON-DOM sent by DomInit.
Depending on what event occured:
DomGetdata(somebuffer);
I could write the manual on this, layout the database structure, but I
would need help with the javascript.
Also this could be done using Tcl on the server, but I think node would
be cleaner, and better in the long run.
I like to collaborate with anyone on the same page,
--
Mike.
--
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
