Re: WOGWT adaptor
Re: WOGWT adaptor
- Subject: Re: WOGWT adaptor
- From: Dan Beatty <email@hidden>
- Date: Tue, 31 May 2011 12:29:07 -0700
- Thread-topic: WOGWT adaptor
Title: Re: WOGWT adaptor
Greetings Michael,
Last time I worked on GWT and Project Wonder AJAX, I ended up writing two academic papers on it: ( http://portal.acm.org/citation.cfm?id=1828885) and ( http://portal.acm.org/citation.cfm?id=1796183.1797057&coll=DL&dl=GUIDE&CFID=24825641&CFTOKEN=12014510). In each of these papers I showed that the GWT mashup has to be loaded by the web browser first. After that, the GWT mashup can call up the WO application be it RESTful, D2W, and etc. The reasons for this is that Project Wonder’s AJAX is still subject to the same server of origin constraint as any other mashup component.
I am currently publishing another paper and in the process of writing yet another. If I get a chance to go to WOWODC, then we could talk about those two articles there. The presentation I am preparing for WOWODC (be I present remotely or live) should have some more tutorial like examples of this phenomina.
I wish that GWT had features that Gianduja was demonstrated to have at WOWODC 2009. It comes close, but would neeed a mini-ORM to work with say HTML5 to synchronize with RESTful engines like ERRest. To accomplish this, one would need a special action for something like Domain Relational Calculus to be included in ERRest. I have simply not had the time to write such a thing. But, it would really be cool.
Thank you,
Dan
On 5/26/11 11:03 AM, "Michael DeMan" <email@hidden> wrote:
Okay, I will investigate this. Thanks!
Yes - I have worked with the Project Wonder Ajax stuff before, but again the company is looking to utilize more broadly accepted technologies where they can, and had pretty much already selected GWT already.
- mike
On May 26, 2011, at 7:16 AM, John Huss wrote:
In GWT, RequestFactory is the way of doing this. It allows you to transfer an object graph to the client and only sends deltas back to the server when things are changed.
It doesn't have push notifications to automatically propagate changes from the server to the clients, but you could implement it fairly simply I think since WO already generates the notification, you just have to have the hanging request waiting and then resend the data as the response.
GWT has a piece called the "Editor framework" which is sort of like a WODisplayGroup - it does data binding to the data objects.
So the main point is that GWT basically has what you need. However, there aren't examples for using WO with it yet. But Google IO just finished and I think there was a lot of sample code that came out of IO that should help to with understanding RequestFactory and the Editors.
Also, if you're not familiar with the Ajax framework in Project Wonder you should look at that first. It allows you to continue developing in the WO way and still get some more dynamic, fancy UIs. It's more of a middle ground between WO and GWT.
John
On Thu, May 26, 2011 at 5:12 AM, Michael DeMan <email@hidden> wrote:
Yeah, I agree that the below e-mail was good.
I have a question on this, and please pardon if I sound somewhat cranky again, but in regards to GWT...
I can see the light at the end of the tunnel to be able to velocity generate the XML beans to get to GWT from both EOF and Cayenne3.1 (w/GUIDs). >From there, just go back 10 years or so to where WO was before other things became more important for the founders/funders of EOF/WO - and the logical was to be able to slide a subset of an EOEditingContext graph of objects back and forth between the client and the server. It would at minimum require at least some kind of authentication delegate to avoid the inevitable troublesome/creative person that might just tweak the client to do unexpected things?
>From there, is there any reason plug-in wise, that for eclipse it would not be possible take those beans 'lightweight / transitory EOs' and be able to wire them up graphically? Basically I guess finish up where WODisplayGroup left us all hanging?
I have been slow on responding on some of this because a lot of the work I've done over the last ten years has been more back end side of things. I backpedaled and got worried I jumped the gun thinking that it was truly necessary to write so many tedious lines of code just to make something show up and be responsive/intuitive to the end user in a browser based application.
I do not want to sound like I'm stuck on GWT - but being able to write normal java code and have it compile to _javascript_ for the client seems to me like a true blessing. The problem is that the APIs are so primitive still? Its like 'oh, we can do a table in the client - as long as all the rows are primitive types and ideally on the back end in a single table'. And, 'oh yeah, its easy, just write all this incredibly tedious and repetitive code for every single scenario that the client side might need to support for your APIs back to the server- and do it three times'.
My thoughts are to extend GWT to be a more full fledged client. That has understandings of things like having a graph of objects, and when modifications are made posting the changes simultaneous both in the client and also back to the server so the server-side EOEditingContext can keep up, etc.
Is this just a dumb idea because I have been so far away from doing client (as in humans) interface work for so long and am just ignorant of advances that have been made?
Presuming that the state of affairs for being able to rapidly wire up client-side interfaces to server-side business logic (yes, I 100% understand it is not that simple) - what do other folks think is the way to go?
Thanks for any feedback, and also my apologies (one more time) if I a just an ignoramus about how tedious it seems to be to build modern 'within the browser' client side apps,
- Mike
On May 24, 2011, at 6:05 AM, Kieran Kelleher wrote:
> Great illustration! I am speechless!
>
> On May 24, 2011, at 8:32 AM, David Avendasora wrote:
>
>> Hi Mike,
>>
>> On May 23, 2011, at 8:17 PM, Michael DeMan wrote:
>>
>>> Yes, I know. The problem is more related to staffing in regards to full time junior software developers and such. Basically, because of the tiny market share WO has, a lot of younger folks perceive it (correctly) as some kind of oddball technology.
>>
>> While it is uncommon, I wouldn't call it oddball. I would call it a secret weapon, and one that uses many of the exact same concepts as iOS, so developing end-to-end enterprise mobile solutions is much, much easier.
>>
>> Find someone with Java experience and interest in iOS and you've got yourself a ready-to-train WebObjects developer.
>>
>>> With a mobile workplace, even kids straight out of college are concerned about what their resume will look like after 3-5 years on a full time job.
>>
>> Those crazy kids. You don't need a resume when people are constantly calling you and offering you jobs! Do they get on the most crowded bus too? Love driving only during rush hour? Pick the longest line in the grocery store?
>>
>> Being a WebObjects developer is like having the HOV lanes open just for your Maserati and having your groceries magically appear in your refrigerator. Sure, you've still got to cook some, but you didn't have to battle half the people in town to get home to dinner.*
>>
>> Dave
>>
>> *Yes, you have to properly configure your Maserati for driving on two-lane roads as opposed to parking lots, and you have to tell the refrigerator what types of food it should accept, but luckily, There's A Property For That™
>>
>> (TAPFT trademark, 2010 Kieran Kelleher)
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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