Home » Modeling » EMF » [GWT] How to transfer EMF models without Google App Engine
| | | |
| Re: [GWT] How to transfer EMF models without Google App Engine [message #639651 is a reply to message #639441] |
Wed, 17 November 2010 10:31   |
 Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi,
A bit late to enter this discussion, but it might be interesting to follow what I am doing with the Texo project
(http://wiki.eclipse.org/Texo). The idea is to offer a standard j2ee/webserver (model-driven) environment on the server
running in a web container (looking also at jetty and osgi currently). Then on the client you can use EMF (either gwt or
standard EMF) using a EMFTexoResource to talk to the server.
See also this recent thread on the EMFT newsgroup:
http://www.eclipse.org/forums/index.php?t=msg&th=199296
We are working on json as well as xml/xmi serialization (also providing a REST function along the way).
gr. Martiin
On 11/16/2010 03:14 PM, Ed Merks wrote:
> Anders,
>
> Comments below.
>
> Anders Forsell wrote:
>> Thanks Ed, my knowledge in GWT is currently very limited. I'm hoping
>> to spend more time in learning this interesting technology, especially
>> now when I can utilize EMF.
>>
>> There are two scenarios that would be interesting to support:
>>
>> 1. When building a REST-based application the current solution seems
>> to work well when using App Engine. Would be nice to support another
>> persistence solution on the server side, though.
> Indeed.
>> Or maybe there are or will be App Engine/Datastore compatible
>> solutions that can be used and installed in a company network?
> That would certainly make sense. Not every enterprise will be
> comfortable storing their data out in the public cloud...
>>
>> 2. When multiple users share model data it would be nice to support
>> GWT clients. This is maybe something for CDO to think about?
> There is support now for optimistic concurrency control but nothing like
> CDO. Certainly on the surface CDO and GWT would seem like a very good
> fit, but the complete lack of synchronous/blocking IO is a show stopper
> I think...
>>
>> Anders
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
| |
| Re: [GWT] How to transfer EMF models without Google App Engine [message #644420 is a reply to message #639441] |
Sat, 11 December 2010 03:14 |
Sam
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
Ed,
We are comfortable using Google cloud, and find GWT/EMF integration very useful for reducing the amount of effort to develop custom code, but ran across few challenges, and I was wondering if there are any suggestions/pointers on how to overcome these. I wasn't able to find anything more relevant on the forum posts...
- First we looked at persistence options for the EMF generated code, which we injected with JDO annotations using custom generator template. It worked relatively well, allowing us to persist on the backend, and use on the fronts end (GWT code), as well as in our custom javascript mapping generated EMF classes to JSON objects. But, because of the JDO bug that precludes super classes from being persisted properly, as well as clunky relationship mapping mechanism for google datastore (using Key references), this option only allowed us to persist separate entities and started defeating the purpose (and motivation) to use EMF. This introduces "extra" relationship management code and does not allow (complicates) for EMF-style model manipulation.
- Inspecting the EMF/GWT generated Editor code, and overall implementation architecture, revealed that persistence using binary blob in datastore is quite efficient and usable, and allows for EMF model manipulation in GWT front end code. (There are some downsides in terms of readability, but manageable). The generated backend (remote interface) serves as a gateway to the datastore, fetching the entire resource and exposing model to GWT javascript in the UI. This works great in the editor, but as we have a custom javascript component (non GWT) that needs to manipulate EMF models, as well as a custom GWT application that needs to have custom UI elements we are wondering what is the best way to extend/integrate with he generated application, so that:
1. The generated remote uriService can be used directly by calling clients written outside of GWT. We have a remote service that exposes business methods to client applications (GWT and custom javascript). Would the best option be using uriService reference inside our remote interface to load resources on the server side? What's the best way to do that?
2. Returning entire resource and populating resource set in the editor is very appropriate, but in our application we most likely need to explicitly load one resource from the datastore, and retain for manipulation. What is the best integration point for being able to do that reusing generated editor? Is there a way to extend/overwrite/customize generated entry point or remote service to load explicit resource by name?
Thanks in advance for any help.
Sam.
|
|
|
| Re: [GWT] How to transfer EMF models without Google App Engine [message #644470 is a reply to message #644420] |
Sat, 11 December 2010 18:08 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Som,
Comments below.
Sam Der-Kazaryan wrote:
> Ed,
>
> We are comfortable using Google cloud, and find GWT/EMF integration
> very useful for reducing the amount of effort to develop custom code,
> but ran across few challenges, and I was wondering if there are any
> suggestions/pointers on how to overcome these. I wasn't able to find
> anything more relevant on the forum posts...
There's not be a lot of discussion...
>
> - First we looked at persistence options for the EMF generated code,
> which we injected with JDO annotations using custom generator
> template. It worked relatively well, allowing us to persist on the
> backend, and use on the fronts end (GWT code), as well as in our
> custom javascript mapping generated EMF classes to JSON objects. But,
> because of the JDO bug that precludes super classes from being
> persisted properly, as well as clunky relationship mapping mechanism
> for google datastore (using Key references), this option only allowed
> us to persist separate entities and started defeating the purpose (and
> motivation) to use EMF. This introduces "extra" relationship
> management code and does not allow (complicates) for EMF-style model
> manipulation.
Relational mapping is always a bit painful. :-( We found that
decomposing into fine grained data store entities as too time consuming;
multiple data store query to reconstruct a resource add up to
significant cost very quickly.
>
> - Inspecting the EMF/GWT generated Editor code, and overall
> implementation architecture, revealed that persistence using binary
> blob in datastore is quite efficient and usable, and allows for EMF
> model manipulation in GWT front end code.
Yes, you can store large things quickly and can transport them efficiently.
> (There are some downsides in terms of readability, but manageable).
Yes, it's very black box.
> The generated backend (remote interface) serves as a gateway to the
> datastore, fetching the entire resource and exposing model to GWT
> javascript in the UI. This works great in the editor, but as we have a
> custom javascript component (non GWT) that needs to manipulate EMF
> models, as well as a custom GWT application that needs to have custom
> UI elements we are wondering what is the best way to extend/integrate
> with he generated application, so that:
>
> 1. The generated remote uriService can be used directly by calling
> clients written outside of GWT.
I don't know anything about how to use things in Javascript directly.
My impression is that the GWT compiler creates a mess of unusable
Javascript...
> We have a remote service that exposes business methods to client
> applications (GWT and custom javascript). Would the best option be
> using uriService reference inside our remote interface to load
> resources on the server side? What's the best way to do that?
Keep in mind that the generated implementation classes can be directly
used in service APIs and transfered by GWT serialization. I'm not sure
that helps. It's important to have a dummy method that uses the white
list (as you can see in the URIService API).
>
> 2. Returning entire resource and populating resource set in the editor
> is very appropriate, but in our application we most likely need to
> explicitly load one resource from the datastore, and retain for
> manipulation.
Note that we don't actually populate all the resource contents. Those
are populated only when you expand the "+". It shouldn't be difficult
to load just individual resources.
> What is the best integration point for being able to do that reusing
> generated editor?
The generated editor is not all the much designed to be reusable at this
point. It's kind of a single giant blob of code that helps show how all
the EMF stuff can be used in a full application.
> Is there a way to extend/overwrite/customize generated entry point or
> remote service to load explicit resource by name?
If you look in the generated editor at how the resource set is created
and configured, you can pretty much get the idea of how to use that same
idea independently in your own application. Using
ResourceSet.getResource is the usual way of loading something. In the
case of GWT, that involves a callback for "notification" when the IO
operation is really completed.
>
> Thanks in advance for any help.
>
> Sam.
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 23:42:54 GMT 2024
Powered by FUDForum. Page generated in 0.03267 seconds |
] 
Search
Help
Register
Login
Home
