Hi John > > > 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 sorry. What I meant is I don't think you can get one of the full fledged web application development environments like Sproutcore, EmberJS, Cappuccino, Angular, MontageJS etc... to work with WebObjects except through REST. Unless I'm missing something it's a one or the other proposition. > 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. I agree but I think the dead end is still a little way off. For people like Apple who have really deep pockets and a lot of smart people Sproutcore makes a lot of sense because it's a great experience. But for small guys like me whose clients tend to be budget restricted WebObjects is still a faster/more economical way to develop. The other two frameworks that I'm tracking closely (Ember and Montage) still don't seem to have completed their data layers. So I'm kind of thinking that in a couple of years they will have been out and will be well tested. > 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. I've started working on an Ajax framework that's like the Project Wonder one but uses JQuery. I'm at the point where I want to experiment with the idea that I originally put out: using custom events to loosely couple web object components on the same page. i.e. Object A subscribes to Object B Object B subscribes to Object A Object A updates via an async ajax request and then sends out a broadcast to the page that it's value has changed. Object B goes OK I'm going to see if my value has changed and polls the server. And vice-versa. An example could be a slider and a textfield that are bound to the same value. > > Johnny > > On Jun 17, 2013, at 11:59 AM, John Huss <johnth...@gmail.com> 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 <jlmil...@kahalawai.com> >> 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 <sam...@samkar.com> 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 <jlmil...@kahalawai.com> a écrit : >> > >> >> Sproutcore? >> >> >> >> >> >> >> >> On Jun 16, 2013, at 6:29 AM, Ramsey Gurley <ramseygur...@gmail.com> 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 <ch...@global-village.net> >> >>>>> To: Baiss Eric Magnusson <bmagnus...@comcast.net> >> >>>>> Cc: WebObjectsDev <webobjects-dev@lists.apple.com> >> >>>>> 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 (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
