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 = [email protected]
::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 <[email protected]>
> 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 <[email protected]>
>>
>> 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/**
>>> raphael4gwt/ <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/**
>>> msg/google-web-toolkit/-/a-**U28tdEaPAJ<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+**
>>> [email protected].
>>> 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.
>
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
