On Monday, June 17, 2013, Johnny Miller wrote: > Hi John, > > I definitely agree it's not the most efficient (or even an efficient) way > to do it. But the problem I'm trying to solve is how do you get one of the > JavaScript frameworks to play nice with component actions? > > It seems like the dilemma is if you want an "app like" UI you need to > completely buy into a solution that has a JavaScript client with a REST > backend. >
Yes, I suppose that's right. But don't over-estimate the difficulty of this task. It's really not that difficult to get something simple working. If you want to go lightweight, on the server you just need a direct action and a json library, like Gson for instance. On the client JQuery makes it pretty easy to make requests and transform page elements. But prototype.js (which the Ajax framework uses already) is fairly easy too. I'm just wondering if there is some kind of middle ground where you can > enhance the existing Ajax framework which lets you use component actions > and D2W to give it a little more app quality to it. It'll never be as good > as these other frameworks but it's an incremental improvement of what we > have now. > > > best, > To me this is a dead end. The separation of client and server becomes more the norm every day with native clients on iOS and Android taking over. Having a REST backend and a JavaScript frontend is really preferable in that case because it makes everything consistent. To address the specific implementation question - to use a component action in Javascript all you need is a component action URL, which you can get by calling context.componentActionURL (if memory serves) or by adding a hidden wo:link or a WOGenericContainer. Then you replace the /wo/ request handler with the Ajax request handler (/ja/ or /ajax/) and fire off your HTTP request. Now you have Ajax component actions. > Johnny > > On Jun 17, 2013, at 11:59 AM, John Huss <[email protected]> wrote: > > Making a server round-trip to update your UI in real time in response to a > mouse event is, at best, inefficient. This sort of thing should be done > client-side (read: in javascript) unless you have a special security > concern or an algorithm that can only realistically be performed on the > server. > > > On Mon, Jun 17, 2013 at 2:51 PM, Johnny Miller <[email protected]>wrote: > > Thank you Samuel, that's very interesting. On something like editing a > pages document or a spreadsheet - do you think the browser sends every > change to the server where the document's "state" is maintained? Or do you > think it builds the document locally and periodically sends the changes to > the server? I haven't tried it yet - do you know if you can work with the > iCloud versions of iWork offline? > > As a side note (OK complete tangent) I've been thinking a lot about > Project Wonder's Ajax framework and your comment kind of reminds me about > an idea I had for creating an ajax element component. The ajax element > would work like the ajax slider where every change (even keystroke) sends a > async request to the server to update the bound object with the new value. > Then the ajax element could broadcast a custom event to the other objects > in the browser that it's value has changed. Other ajax elements like ajax > update containers could subscribe for that event and when they receive it > initiate their own request to the server to see if their value has changed. > This way Wonder could imitate the bidirectional communication that you see > in other frameworks i.e. http://montagejs.org/docs/data-binding.html > > Sorry to go off on a tangent like that but it's been what I've been > thinking about this weekend and I haven't had anybody to discuss it with ;) > > Best, > > Johnny > > > On Jun 17, 2013, at 4:34 AM, Samuel Pelletier <[email protected]> wrote: > > > The are many javascript libraries in the source, the credits part list > Jison, Sizzle, BinaryAjax, Javascript EXIF Reader, Prototype, jQuery, > Sproutcore and yui. > > > > For the server part, the Ajax url are not like WO urls. For such a large > scale and very specialized deployment they probably have something very > optimized for fast response with async server side processing of the > validation and save to persistent storage. This way, you can batch many > small transactions into a single IO intensive process. Almost every > keystrokes create a request like google apps. > > > > Samuel > > > > Le 2013-06-16 à 15:25, Johnny Miller <[email protected]> a écrit : > > > >> Sproutcore? > >> > >> > >> > >> On Jun 16, 2013, at 6:29 AM, Ramsey Gurley <[email protected]> > wrote: > >> > >>> I'm gonna go out on a limb and say, something closed source that they > have no plan to ever share with us :-) > >>> > >>> On Jun 16, 2013, at 9:04 AM, Stavros Panidis wrote: > >>> > >>>> Well, what is the technology Apple uses for iWork for iCloud? > >>>> > >>>> Stavros Panidis > >>>> > >>>>> ------------------------------ > >>>>> > >>>>> Message: 7 > >>>>> Date: Sat, 15 Jun 2013 08:54:28 -0700 > >>>>> From: Chuck Hill <[email protected]> > >>>>> To: Baiss Eric Magnusson <[email protected]> > >>>>> Cc: WebObjectsDev <[email protected]> > >>>>> Subject: Re: Can WOWODC folks make this happen some day > >>>>> Message-ID: <1B9C50E3-F1 > >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
