> > "Swing approach", as in javax.swing, i.e. build a UI once and run it > everywhere, with theming to try to blend it with the platform. > "native UI" as in Android's android.widget.Button vs. Cocoa's NSButton or > UIKit's UIButton, vs. WPF's System.Windows.Controls.Button vs. HTML's > <button>, i.e. build the UI with the tools native to the target platform. >
Well, *we* don't do that. GWT widgets and the UI code that drives them that way is only for the web. Underlying code is shared, but not the actual presentation. However, the widgets do give us a level of abstraction and related freedom with respect to add-ons that others make for our product. We can evolve our product and have greater flexibility in changing how it looks and behaves when add-ons use our widgets as main building blocks. They bring main navigational and other user experience paradigms, not just looks which could be handled by CSS. With respect to various forms of buttons you mention as an example we would have abstracted that, not taken the javax.swing approach of reimplementing them. I do not know what others are doing. > Fwiw, I had started working on it almost 2 years ago, and Daniel (Kurka) > told me he went that path too, but eventually abandoned as it was > relatively easy to port generators to annotation processors. And that was > indeed my experience as well when porting the PlaceHistoryMapper generator > over to APT as aprood of concept: https://github.com/tbroyer/gwt-places > I like APT better over the other form of generators too. My problem isn't about that exactly.In our case the problem is what do we do with 3rd party libraries we depend on that need whatever they may and, more directly, the fact that we cannot generate additional synthetic (de)serialization methods without regenerating the entire type - and we'd need to do that to gain access to anything that isn't public. No, not all fields should have getters and certainly not setters. > Btw, I'd really like it if for development only j2cl was needed, without > the closure-compiler pass (now that most browsers support ... > > I'd like the same thing for some other reasons too. I am mostly coming from the perspective of efficiently delivering and combining our code with add-on code at customer (install-time or run-time). > Furthermore, how do we make the compiler generate code that accesses >> private fields? >> > > This is a very good question, and it seems like it would be the only > blocker. > > Yes. So, what we'd need is that this is at least allowed. Thanks for the rest of the info. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/c1b7fe7c-a150-4896-a6d8-e36a189e5dfe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
