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] <javascript:>>
>
>> 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/, 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.
>>
>> 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/-/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.
