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 librariesto 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: 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. > .... 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]. 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.
