Re: WOGWT adaptor
Re: WOGWT adaptor
- Subject: Re: WOGWT adaptor
- From: Michael DeMan <email@hidden>
- Date: Thu, 26 May 2011 03:12:46 -0700
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