Home » Modeling » EMF » [GWT] Customization / Magic
|
| Re: [GWT] Customization / Magic [message #649635 is a reply to message #649632] |
Thu, 20 January 2011 01:33   |
 Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Miles,
Comments below.
Miles Parker wrote:
> Hi all,
>
> I'm really excited about the GWT functionality but am having a hard
> time figuring out how to customize the components, get access to the
> resources from other components and modules, etc..
Are you talking about properties and images? GWT has its own funky way
of get at ushc resources, but in the end we're making sure that the
generated EMF plugins can access them in the usual way.
> Unlike the IDE and RAP support it doesn't seem that there are actual
> editors, resource factories, etc.. generated?
Only BinaryResourceImpl is supported. The GWT client just doesn't have
the libraries needed to support SAX or DOM...
> It seems that a lot is going on magically behind the scenes
Yes, mostly.
> and I'm hoping to see the curtain lifted a bit. :d
Most of the stuff (model and edit are) are like normal. The editor is
effectively a generic editor all in one giant file in
EditorEntryPoint. It's not designed (yet) to be very customizable, but
rather to illustrate what's possible. Most likely this is the scene
behind which you'll want to look most.
In terms of the runtime, things like DatastoreURIHandlerImpl and
DatastoreUtil will be of interest.
> Miles
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [GWT] Customization / Magic [message #649637 is a reply to message #649635] |
Thu, 20 January 2011 02:21 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
| Ed Merks wrote on Wed, 19 January 2011 20:33 |
Are you talking about properties and images? GWT has its own funky way of get at ushc resources, but in the end we're making sure that the generated EMF plugins can access them in the usual way.
..
|
Nope, that all works great -- I'm confident I can customize the behavior and L&F of the built-in editor to my heart's content. What I want to do is to break out of the editor.
| Quote: | The editor is effectively a generic editor all in one giant file in EditorEntryPoint. It's not designed (yet) to be very customizable, but rather to illustrate what's possible. Most likely this is the scene behind which you'll want to look most.
|
Exactly. Just to be clear what I'm shooting for, an example use case:
1. User goes to coolapp.com
2. Shared model is loaded automatically from some known data source.
3. User sees a completely customized (and very simple) UI that contains features from the model.
In other words, I don't really need .editor per se at all except with my very limited knowledge of GWT it is the only place I can think to start from.
That's why I was hoping to see something like CoolAppEditor, where I could see how things are done in #createPages and #createModel, and go form there.
| Quote: | Only BinaryResourceImpl is supported. The GWT client just doesn't have the libraries needed to support SAX or DOM...
In terms of the runtime, things like DatastoreURIHandlerImpl and DatastoreUtil will be of interest.
|
That's no problem, I just need to be able to get to some arbitrary resource on the App engine store and wasn't clear how to do that. Your answer is prob. the hint I needed. Still as with the editor issue above, one of the really great things about EMF IDE generation is that if you want to do something it is easy to just look at the generated code to get a place to start from. But of course I can just look at the library code instead.
thanks Ed,
Miles
|
|
| | |
| Re: [GWT] Customization / Magic [message #649935 is a reply to message #649934] |
Fri, 21 January 2011 05:40 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------090202030404060306040003
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sam,
No, that works correctly for me. Try setting a breakpoint in
EMFEditPlugin and see what's happening *here*:
@Override
public String getString(String key, Object [] substitutions,
boolean translate)
{
if ("_EXC_Method_not_implemented".equals(key)) return
PROPERTIES.excMethodNotImplemented(substitutions[0]);
else if ("_UI_CreateChild_text".equals(key)) return
PROPERTIES.createChildText(substitutions[0]);
else if ("_UI_CreateChild_tooltip".equals(key)) return
PROPERTIES.createChildTooltip(substitutions[0], substitutions[1]);
else if ("_UI_CreateChild_description".equals(key)) return
PROPERTIES.createChildDescription(substitutions[0],
substitutions[1], substitutions[2]);
else if ("_UI_CreateSibling_description".equals(key)) return
PROPERTIES.createSiblingDescription(substitutions[0],
substitutions[1], substitutions[2]);
else if ("_UI_CreateChildCommand_label".equals(key)) return
PROPERTIES.createChildCommandLabel(substitutions[0]);
else if ("_UI_Property_description".equals(key)) return
PROPERTIES.propertyDescription(substitutions[0], substitutions[1]);
* else if ("_UI_CreateChild_text2".equals(key)) return
PROPERTIES.createChildText2(substitutions[0], substitutions[1]);
else if ("_UI_CreateChild_text3".equals(key)) return
PROPERTIES.createChildText3(substitutions[1]);*
else return key;
}
Sam Der-Kazaryan wrote:
> That's an interesting concept. I'll try that as well.
>
> What I noticed is that _UI_CreateChild_text(1/2) externalized
> variables from plugin.properties do not get substituted properly, so
> the editor actually displays the property names, not the values. For
> example, if you click "Create" on model entities, the choices in the
> pulldown are "New _UI_CreateChild_text", not the actual entity type
> names.
>
> For some reason I recall in prior version this working differently...
> Do you see similar behavior?
>
--------------090202030404060306040003
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Sam,<br>
<br>
No, that works correctly for me. Try setting a breakpoint in
EMFEditPlugin and see what's happening <b>here</b>:<br>
<blockquote><small> @Override</small><br>
<small> public String getString(String key, Object [] substitutions,
boolean translate)</small><br>
<small> {</small><br>
<small> if ("_EXC_Method_not_implemented".equals(key)) return
PROPERTIES.excMethodNotImplemented(substitutions[0]);</small ><br>
<small> else if ("_UI_CreateChild_text".equals(key)) return
PROPERTIES.createChildText(substitutions[0]);</small><br>
<small> else if ("_UI_CreateChild_tooltip".equals(key)) return
PROPERTIES.createChildTooltip(substitutions[0], substitutions[1]);</small><br>
<small> else if ("_UI_CreateChild_description".equals(key)) return
PROPERTIES.createChildDescription(substitutions[0], substitutions[1],
substitutions[2]);</small><br>
<small> else if ("_UI_CreateSibling_description".equals(key))
return PROPERTIES.createSiblingDescription(substitutions[0],
substitutions[1], substitutions[2]);</small><br>
<small> else if ("_UI_CreateChildCommand_label".equals(key))
return PROPERTIES.createChildCommandLabel(substitutions[0]);</small ><br>
<small> else if ("_UI_Property_description".equals(key)) return
PROPERTIES.propertyDescription(substitutions[0], substitutions[1]);</small><br>
<b><small> else if ("_UI_CreateChild_text2".equals(key)) return
PROPERTIES.createChildText2(substitutions[0], substitutions[1]);</small><br>
<small> else if ("_UI_CreateChild_text3".equals(key)) return
PROPERTIES.createChildText3(substitutions[1]);</small></b> <br>
<small> else return key;</small><br>
<small> }</small><br>
</blockquote>
<br>
<br>
Sam Der-Kazaryan wrote:
<blockquote cite="mid:ihb4qu$62k$1@news.eclipse.org" type="cite">That's
an interesting concept. I'll try that as well.
<br>
<br>
What I noticed is that _UI_CreateChild_text(1/2) externalized variables
from plugin.properties do not get substituted properly, so the editor
actually displays the property names, not the values. For example, if
you click "Create" on model entities, the choices in the pulldown are
"New _UI_CreateChild_text", not the actual entity type names.
<br>
<br>
For some reason I recall in prior version this working differently...
Do you see similar behavior?
<br>
<br>
</blockquote>
</body>
</html>
--------------090202030404060306040003--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | |
| Re: [GWT] Customization / Magic [message #649939 is a reply to message #649936] |
Fri, 21 January 2011 06:10 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
| Sam wrote on Fri, 21 January 2011 00:56 | I accomplished what you are looking for by adopting resource loding code that is in the generated editor into the remote service generated by GWT. My resources are loaded from the datastore, manipulated on the server side, and passed to UI as JSON objects. In other words, separate objects not the entire resource is present in the front end. To do this, you need to consider that resources are loaded "locally" in this case, so you need to eliminate remote service lookup and write your own URIHandlerImpl. Hint: My servlet extends URIHandlerImpl. Depending on what you are trying to accomplish in your application, this approach may be an overkill. However, I thought I'd share.
|
On the my little corner of the earth scale, in order to accomplish the basics of what I wanted I took a hint from Ed on other thread and modified the resource load call back such that it set the tree item provider to the set of objects I wanted from my specific resource. Worked like a charm, and it looks quite easy to populate any widgets in this way. Of course, that doesn't address all of the galactic scale issues but it works well enough for prototyping. See the other recent GWT thread for some interesting issues on the galactic scale but it seems like we should be able to figure out a way to manage the objects as EMF on the server side as well. Then you can use EMF / BinaryResource everywhere.
Now, what is this "JSON" thing that you speak of? 
|
|
| | | | | | | | | |
| [GWTish] Document-Oriented Back-Ends [message #650453 is a reply to message #649943] |
Tue, 25 January 2011 01:57 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
| Sam wrote on Fri, 21 January 2011 01:24 | JSON - javascript object encoding used for data transfer (think lightweight entity serialization). There are some implications using it, such as relationship mapping can be tricky...
|
btw, I was kidding..  but I've actually been using JSONP a lot on the output end for EMF / XPand stuff. In particular, I've been building Exhibits using the MIT SIMILE toolset. It is in some ways a very different way of thinking about data.
Again, as I mentioned in the other post, I think the "everything old is new again" thing is playing itself out. I don't know about your experience but at least when I was taking my run of the mill CS courses, the difference between various data representation models was always portrayed as an onward and upward sort of thing. The myth of progress.. First we had tables and hierarchical models and then along came Relational Models and finally the Object Model, which of course kicked ass on everything else. But it isn't the case at all.
The real world is composed in all kinds of different contextualized ways and there is no single representational meta-scheme -- i.e. hierarchical, relational, object and various sub-classifications -- that is going to be ideal for every possible use. I don't know if anyone has formalized that rule, but if we did, it would be a variation of Wolpert and Macready's No Free Lunch theorem showing the impossibility of defining a search algorithm that would fit all cases, *even when that search algorithm was designed to explore multiple search options*. The belief that there is one single privileged way to represent everything -- and we only need to discover it -- is sort of a never quite stated dream system for many of us CS types. But it's impossible, which explains why for example UML has never quite lived up to it's overly ambitious promises and why we always have this sense in the back of our minds that there has to be a better way to do things -- because there always is!
What does this have to do with EMF and different approaches to data stores? The technology that is most flexible, practical, and least dogmatic will win, and the basic reason I like EMF is that I think it nails each one of those. And we're seeing the expression of that with all of the different front ends and now the ability to map to very different back-ends and most importantly entirely different approaches to representing data.
cheers,
Miles
|
|
|
| Re: [GWTish] Document-Oriented Back-Ends [message #650607 is a reply to message #650453] |
Tue, 25 January 2011 16:57 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Miles,
Comments below.
Miles Parker wrote:
> Sam wrote on Fri, 21 January 2011 01:24
>> JSON - javascript object encoding used for data transfer (think
>> lightweight entity serialization). There are some implications using
>> it, such as relationship mapping can be tricky...
>
>
> btw, I was kidding.. :p but I've actually been using JSONP a lot on
> the output end for EMF / XPand stuff. In particular, I've been
> building Exhibits using the MIT SIMILE toolset. It is in some ways a
> very different way of thinking about data.
>
> Again, as I mentioned in the other post, I think the "everything old
> is new again" thing is playing itself out. I don't know about your
> experience but at least when I was taking my run of the mill CS
> courses, the difference between various data representation models was
> always portrayed as an onward and upward sort of thing. The myth of
> progress.. First we had tables and hierarchical models and then along
> came Relational Models and finally the Object Model, which of course
> kicked ass on everything else. But it isn't the case at all.
Rinse, lather repeat. Each generation is so much more brilliant than
the past, and is therefore doomed to repeat all the mistakes because
they're sure they'll be able to overcome the problems.
>
>
> The real world is composed in all kinds of different contextualized
> ways and there is no single representational meta-scheme -- i.e.
> hierarchical, relational, object and various sub-classifications --
> that is going to be ideal for every possible use.
One size fits all tends to be in the form of a capacious moo moo.
> I don't know if anyone has formalized that rule, but if we did, it
> would be a variation of Wolpert and Macready's No Free Lunch theorem
> showing the impossibility of defining a search algorithm that would
> fit all cases, *even when that search algorithm was designed to
> explore multiple search options*. The belief that there is one single
> privileged way to represent everything -- and we only need to discover
> it -- is sort of a never quite stated dream system for many of us CS
> types. But it's impossible, which explains why for example UML has
> never quite lived up to it's overly ambitious promises and why we
> always have this sense in the back of our minds that there has to be a
> better way to do things -- because there always is!
It's better to focus on the underlying equivalence of representations
than to look for the one "best" one.
>
> What does this have to do with EMF and different approaches to data
> stores? The technology that is most flexible, practical, and least
> dogmatic will win, and the basic reason I like EMF is that I think it
> nails each one of those.
I hope so.
> And we're seeing the expression of that with all of the different
> front ends and now the ability to map to very different back-ends and
> most importantly entirely different approaches to representing data.
I'm especially happy with some of the progress in improved flexibility
in https://bugs.eclipse.org/bugs/show_bug.cgi?id=308136 It makes
plugging in MongoDB support as easy as implementing a new URIHandler...
>
> cheers,
>
> Miles
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Sat Apr 20 01:12:11 GMT 2024
Powered by FUDForum. Page generated in 0.04117 seconds |
] 
Search
Help
Register
Login
Home
