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 protected]> 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 protected]> 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 protected]) >>>>> >> Help/Unsubscribe/Update your Subscription: >>>>> >> >>>>> http://lists.apple.com/mailman/options/webobjects-dev/kelleherk%40gmail.com >>>>> >> >>>>> >> This email sent to [email protected] >>>> > >>>> > _______________________________________________ >>>> > Do not post admin requests to the list. They will be ignored. >>>> > Webobjects-dev mailing list ([email protected]) >>>> > Help/Unsubscribe/Update your Subscription: >>>> > >>>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40deman.com >>>> > >>>> > This email sent to [email protected] >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/johnthuss%40gmail.com >>> >>> This email sent to [email protected] >> > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/daniel.beatty%40navy.mil > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
