Interesting, hhmmm.. But I would prefer JSON to Client Model, instead to DOM. And important changes or submit of the client model, travels via JSON to server. The client code decides what to do with, ie., a new piece of the client model sent from the server: update a page area, open a new window/view, refresh the full page, etc.. I guess this is more aligned to a MVC-like app. The M would be what I called the Client Model.
Another approach: start to use WebSockets, socket.io, if you new a more "two-way" communication btw client,server instead relying on client Ajax calls/polling. BTW, there are interesting MVC implementation in Javascript. Yesterday, I met Ambient http://angularjs.org/#/ Angel "Java" Lopez http://www.ajlopez.com http://twitter.com/ajlopez On Sat, Feb 11, 2012 at 9:23 PM, Michael Anderson <[email protected]>wrote: > ** > 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 > -- 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
