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 =
> [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] <javascript:>>
>
>> 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]<javascript:>
>> .
>> To unsubscribe from this group, send email to
>> [email protected] <javascript:>.
>> 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 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 [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.
