Answer below in Bold. Cheers
2012/9/11 Sebastián Gurin <sebastigu...@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/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 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.
