Hi Greg,

I have been in IT for a very long time. You see, I am what the youngins
sometimes refer to as an ol' fart :). As a matter of fact, I've been a
developer in one form or another for so long that everything else prior to
that seems to me to be prehistory - a vague sense of something there but not
having much substance (oh GOD, help me lol).

My point is that as technologies advance I try to stay current and for those
technologies that I have or will chose to base a career on I've tried to
master them to the best of my ability. That means giving up lots of personal
time to read up on everything I can get my hands on. Why the story? Because
I am trying to convey to you that there are no shortcuts or free lunches. If
you want to be a master Web applications developer then you will have to
read and learn everything you can about Web development that you can get
your hands on. It is that simple, I am afraid. The benefits are obvious, as
the current limitations you perceive there to be in the GWT documents serve
to exemplify.

I'm afraid that comparing Google to other companies, even if only for their
quality of documentation, isn't going to be very productive and will just
serve to frustrate you even more. Take the time and go and read, read, read,
and play with all the different things you do read up on. One day soon you
will have what can only be described as an epiphany, that moment when it all
gels and at that moment you will have a big smile on your face - a Kodak
moment!

Jeff




On Tue, Dec 7, 2010 at 12:08 PM, Greg Dougherty
<[email protected]>wrote:

> > > If I knew JavaScript and DOM, or, for that matter, even WANTED to know
> > > JavaScript and DOM, I wouldn't be using GWT, I'd be writing the
> > > JavaScript myself.  No?
> >
> > No.
> >
> > Abstractions do not work for these kind of things.
>
> It's not a matter of abstractions, it's a matter of explanations.
> IMAO, the JavaDoc for a KeyPressEvent should tell you exactly what
> that event IS.  And what's the difference between it and the other
> Key*Events.  It shouldn't be that hard, after all the person writing
> the code had better know the answer to that question, no?
>
> Google has detailed requirements for the format of any code submitted
> to be part of GWT.  How about a requirement that the documentation
> attached to the code actually has to provide some value, too?
>
> And I think you're confusing this post (about trying to figure out
> which event to use) with my other post (where the tutorial code for
> getting an enter key doesn't work).
>
> The point of THIS thread is that the people writing "documentation"
> for a lot of the GWT routines seem to assume that everyone using GWT
> spends as much time reading W3C documentation as the doc writers do,
> and as such they end up writing documentation that is worthless until
> you go read the W3C docs (or come here and beg for information).  The
> further point is that this is a bad assumption on their part, and that
> it would be good if they stopped writing docs that way.
>
> Greg
>
> On Dec 4, 6:11 am, Thomas Broyer <[email protected]> wrote:
> > On 3 déc, 20:50, Greg Dougherty <[email protected]> wrote:
> >
> > > Jeff,
> >
> > > Thank you.  That' lets me know which one I want to use.
> >
> > > If I knew JavaScript and DOM, or, for that matter, even WANTED to know
> > > JavaScript and DOM, I wouldn't be using GWT, I'd be writing the
> > > JavaScript myself.  No?
> >
> > No.
> >
> > Abstractions do not work for these kind of things. GWT is no different
> > from jQuery, Prototype.js and others in this respect: it tries to hide
> > browser discrepancies, but that doesn't mean you're freed from knowing
> > them (or least that they exist).
> > What GWT gives you that JavaScript doesn't is that it's Java, i.e. you
> > can reuse some code between your (Java) server and client, you benefit
> > from Java's static typing (which among other things make refactoring
> > efficient), you benefit from the tools from the Java world.
> > (don't put words in my mouth though: there are drawbacks to using Java
> > compared to JavaScript, they're two different languages, each with
> > their own strengths)
> >
> > > The whole point of using something like GWT is that it lets a Java
> > > programmer write a web app w/o having to learn all the crap that
> > > normal web app writers have to wade through.  That's certainly why I
> > > spent the time and effort to learn GWT.  For that matter, I presume
> > > that the people writing things like the KeyPressEventHandler DO know
> > > JavaScript and DOM.  So, really, how hard is it for them to put that
> > > knowledge into the documentation?  Isn't that what the documentation
> > > is THERE for?
> >
> > The problem is that key/char event is a real mess!
> > All browsers behave differently (though WebKit is really close to IE).
> > Different successive versions of a given browser don't behave the
> > same. The same version of a given browser behave different on
> > different platforms.
> > It's hard (if ever possible!) to build an API with a consistent
> > behavior.
> > See for instance, and amongst many:
> http://code.google.com/p/google-web-toolkit/issues/detail?id=72http://code.google.com/p/google-web-toolkit/issues/detail?id=1061http://code.google.com/p/google-web-toolkit/issues/detail?id=1529http://code.google.com/p/google-web-toolkit/issues/detail?id=4092
>
> --
> 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]<google-web-toolkit%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>
>


-- 
*Jeff Schwartz*

-- 
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.

Reply via email to