I use WOGWT (actually SmartGWT with GWTRPC with WO5.3 and now WO5.4).
I used WOGWT directly inside a WO project, but now have separated it
completely and am making sure I have no problems just using the
generated front-end separate from the WO back-end. So far no
problems. Still small project at the moment. But I do love SmartGWT
(I don't bother to deviate from their provided skins much, but I know
I still can to some degree, of course less than with just GWT).
I can try to answer questions directly as best as I can.
= Robert B. Hanviriyapunt =
[email protected]
On May 26, 2011, at 1:03 PM, Michael DeMan 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/roberthana%40scologistics.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/archive%40mail-archive.com
This email sent to [email protected]
