Re: Webobjects-dev Digest, Vol 10, Issue 389

Subject: Re: Webobjects-dev Digest, Vol 10, Issue 389
From: Johnny Miller <email@hidden>
Date: Mon, 17 Jun 2013 17:11:00 -1000

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 <email@hidden> 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@hidden> 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@hidden> 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@hidden> a écrit :
>
>> Sproutcore?
>>
>>
>>
>> On Jun 16, 2013, at 6:29 AM, Ramsey Gurley <email@hidden> 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@hidden>
>>>>> To: Baiss Eric Magnusson <email@hidden>
>>>>> Cc: WebObjectsDev <email@hidden>
>>>>> 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@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References:
	>Re: Webobjects-dev Digest, Vol 10, Issue 389 (From: Stavros Panidis <email@hidden>)
	>Re: Webobjects-dev Digest, Vol 10, Issue 389 (From: Ramsey Gurley <email@hidden>)
	>Re: Webobjects-dev Digest, Vol 10, Issue 389 (From: Johnny Miller <email@hidden>)
	>Re: Webobjects-dev Digest, Vol 10, Issue 389 (From: Johnny Miller <email@hidden>)
	>Re: Webobjects-dev Digest, Vol 10, Issue 389 (From: John Huss <email@hidden>)
	>Re: Webobjects-dev Digest, Vol 10, Issue 389 (From: Johnny Miller <email@hidden>)
	>Re: Webobjects-dev Digest, Vol 10, Issue 389 (From: John Huss <email@hidden>)

Prev by Date: Re: Webobjects-dev Digest, Vol 10, Issue 389
Next by Date: ec.SaveChanges and relationship
Previous by thread: Re: Webobjects-dev Digest, Vol 10, Issue 389
Next by thread: ec.saveChanges and update error : updateValuesInRowDescribedByQualifier
Index(es):
- Date
- Thread