The GPE provides some help with JSNI.
But at some point you will have to write some JS by hand with no
autocompletion :)
2012/9/15 Sebastián Gurin <sebastigu...@gmail.com>
> nino: thank you very much! I have my two question responded in your code
> snippet. My last question: I notice you perform most of the job in
> javascript / jsni, nice. How is your experience using eclipse+google Java
> code refactoring tools ? in particular, method and class renames ? Thank
> you again.-
>
> On Thursday, September 13, 2012 5:51:30 PM UTC-3, nino wrote:
>
>> In one our our project we have a base which goes something like
>>
>> public class ProxyObject {
>>
>> protected JavaScriptObject jsObj;
>>
>> protected ProxyObject() {
>>
>> }
>>
>> }
>>
>>
>> The we do
>>
>> public class View extends ProxyObject {
>>
>> public View() {
>>
>> createPeer();
>>
>> }
>>
>>
>> View(JavaScriptObject obj) {
>>
>> jsObj = obj;
>>
>> }
>>
>>
>> private List<View> children = new ArrayList<View>();
>>
>> @Override
>>
>> public native Point getAnchorPoint() /*-{
>>
>> var jso = th...@com.emitrom.gwt4.ti.**mobile.client.core.ProxyObject**
>> ::getJsObj()();
>>
>> var obj = jso.anchorPoint;
>>
>> var toReturn = @com.emitrom.gwt4.ti.mobile.**client.ui.Point::new(Lcom/*
>> *google/gwt/core/client/**JavaScriptObject;)(obj);
>>
>> return toReturn;
>>
>> }-*/;
>>
>> }
>>
>> We create the wrapped JSO in the constructor and delegation is done
>> using JSNI which save the need of the explicit cast.
>>
>> To call methods on the wrapped JSO we use JSNI
>>
>>
>> Hope this could help
>>
>>
>>
>> 2012/9/13 Sebastián Gurin <sebast...@gmail.com>
>>
>> Hi nino, i'm making a second Java API for my yuigwt project, on top of my
>>> JSO based Java API, wrapping JSO objects and delegating methods to it. I
>>> have a couple of questions for you about this. I'm not sure, perhaps the
>>> best is to create another thread for this questions, but here they go:
>>>
>>> I have a rich class hierarchy for example, ClassC extends ClassB extends
>>> ClassA
>>>
>>> Now for ClassA I'm writing:
>>>
>>> public class ClassA {
>>> protected JSOClassA _wrapped;
>>> }
>>>
>>> The problem is that in ClassB and ClassC I must cast _wrapped to
>>> JSOClassB and JSOClassC for implementing method delegation, so I ended with
>>> something like
>>>
>>> public class ClassB extends ClassA {
>>> protected JSOClassB _wrappedClassB() {
>>> return _wrapped.cast();
>>> }
>>> }
>>> public class ClassC extends ClassB {
>>> protected JSOClassC _wrappedClassC() {
>>> return _wrapped.cast();
>>> }
>>> }
>>>
>>> can you think of another more simpler way to solve this ?
>>>
>>> And the other question is, how or where should I initialize the _wrapped
>>> field ? at constructor ?
>>>
>>> Regards and thanks in advance.
>>>
>>> On Tuesday, September 11, 2012 7:24:56 AM UTC-3, nino wrote:
>>>
>>>> Answer below in Bold.
>>>>
>>>> Cheers
>>>>
>>>> 2012/9/11 Sebastián Gurin <sebast...@gmail.com>
>>>>
>>>> Nino; I very like your thoughts and I agree with them. My reply between
>>>>> lines:
>>>>>
>>>>> On Monday, September 10, 2012 5:05:25 PM UTC-3, nino wrote:
>>>>>>
>>>>>> The main Question is do you want YUI users to use Java or do you want
>>>>>> to bring Java Devs to YUI ?
>>>>>> I think you will get more traction by choosing the latter.
>>>>>>
>>>>>>
>>>>> I also thought of that. I started learning how to port JavaScript
>>>>> libraries to GWT with my project http://code.google.com/p/**rapha**
>>>>> el4gwt/ <http://code.google.com/p/raphael4gwt/> , a vector drawing
>>>>> library. As such, performance was a requirement, and then a Java API using
>>>>> GWT overlays directly was a requirement. But now for YUIGWT I wonder if
>>>>> that is true. Some notes:
>>>>>
>>>>
>>>>
>>>> *Yeah overlay type can be inherited but there is not much u
>>>> can do with that.Plus the methods beeing all finals one cant override them.
>>>> Not really flexible imho*.
>>>>
>>>>>
>>>>> 1) overlay types CAN be inherited, but I agre that is very
>>>>> unconfortable for end GWT/Java users to do this... this is a very
>>>>> important "issue" in my project I think...
>>>>> 2) I very liked your question: "do you want YUI users to use Java or
>>>>> do you want to bring Java Devs to YUI ? " and it is making me reflect a
>>>>> lot. thanks.
>>>>>
>>>>>
>>>>>> While a zero overhead API gives you the ability to easely write YUI
>>>>>> code in java soon you will get users request like "Why cant i extends
>>>>>> class X to add my own functions". Overlay types dont give you.
>>>>>>
>>>>>> We had this problems while implementing our libraries. We started
>>>>>> first with 1:1 match of the JS API. Until our users start complaining
>>>>>> about
>>>>>> the API not beeing extensible. What you would expect when using an OO
>>>>>> language like Java.
>>>>>>
>>>>>
>>>>> Well, but tell me, do you write a second Java API, with real java
>>>>> classes that wrapp the Js objects ? and if so, do you use your previous
>>>>> 1:1
>>>>> Java API for writing the this second more-java-confortable API? (I sould
>>>>> do that) and if so, do you use some Java code generator tool for
>>>>> artificial
>>>>> create the second Java API form the first 1:1 - overlays Java API ? can
>>>>> this be mechanized at all?
>>>>>
>>>>> I'm questioning my self these kind of things for my project YUIGWT.
>>>>> YUI has a very big API, and unlike other libraries it contains utils for
>>>>> doing a more structured - object oriented javascript like classes,
>>>>> inheritance, plugins, attributes, events, etc. All artificially and fully
>>>>> extensible from javascript. The big desicion I have to make is this:
>>>>> "the objective of YUIGWT is to bring the YUI public concrete utilities to
>>>>> the GWT user, like a datatable, a button, etc ". But not to support
>>>>> those utilities enhancing the Javascript language.
>>>>>
>>>>
>>>>
>>>> *We dont use generator for our APIs. We go the insane way to look at
>>>> each methods in the APIs we try to wrap! This is a lot of work but it gives
>>>> us the possibility to optimize/enhendce some stuff. And sometime leave some
>>>> stuff out that dont make sence for a Java Developer. Plus you come to learn
>>>> the JS library which is not bad (At my day to day work i dont use GWT but
>>>> EXTJS. So Wrapping ExtJS helped me understand that library better, and
>>>> hate it even more loooool). *
>>>> * *
>>>> * Concerning building the objects. Like i said before we basically
>>>> have a real Java Object wrapping a JSO. And we are just delegating to the
>>>> native JSO. You can have a look at our Java API for Sencha Touch (
>>>> http://emitrom.com/touch4j) to see it in action.*
>>>> * *
>>>> * If you have any question feel free to ping me.*
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>> .... code....
>>>>>>
>>>>>> That looks pretty cool. Now what if i want to extend Button and
>>>>>> override some methods ?
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> This is the perfect example, thank you!
>>>>>
>>>>> Currently in my YUIGWT project (very new project) I do not contemplate
>>>>> that. What I'm thinking can be a perfect solution for me is : to create a
>>>>> second Button class, that wraps all current Button methods, as you
>>>>> suggested in your first post. The user could override some methods, and it
>>>>> is his responsability to call super.(). In the constructor, they must pass
>>>>> me the Y object that is responsible for instantiate the "real - native"
>>>>> Button .
>>>>>
>>>>> Well, a pleasure to read you, if you have any other suggestions or
>>>>> tips about this subject are most welcome.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Google Web Toolkit" group.
>>>>> To view this discussion on the web visit https://groups.google.com/d/*
>>>>> *ms**g/google-web-toolkit/-/a-**U28td**EaPAJ<https://groups.google.com/d/msg/google-web-toolkit/-/a-U28tdEaPAJ>
>>>>> .
>>>>>
>>>>> To post to this group, send email to google-we...@**googlegroups.com.
>>>>>
>>>>> To unsubscribe from this group, send email to google-web-toolkit+**
>>>>> unsubscribe**@googlegroups.com.
>>>>> For more options, visit this group at http://groups.google.com/**group
>>>>> **/google-web-toolkit?hl=en<http://groups.google.com/group/google-web-toolkit?hl=en>
>>>>> **.
>>>>>
>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Google Web Toolkit" group.
>>> To view this discussion on the web visit https://groups.google.com/d/**
>>> msg/google-web-toolkit/-/**pAMwpwmGowMJ<https://groups.google.com/d/msg/google-web-toolkit/-/pAMwpwmGowMJ>
>>> .
>>>
>>> To post to this group, send email to google-we...@**googlegroups.com.
>>> To unsubscribe from this group, send email to google-web-toolkit+**
>>> unsubscr...@googlegroups.com.
>>> For more options, visit this group at http://groups.google.com/**
>>> group/google-web-toolkit?hl=en<http://groups.google.com/group/google-web-toolkit?hl=en>
>>> **.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/google-web-toolkit/-/MNdypItk-VUJ.
>
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
