Hi, I'm using protected members, nothing private. So any change to those methods in the Widget API will break compatibility for a lot of projects. But regardless, if the widget API is ever changed or something better is created that would allow us to use Renderers and do it in a supported way then I would be glad to migrate my code.
I am not the only one who has moved to this direction. I am currently working on a second project that uses about the same approach, developed before I ever talked to the developers in that team/company. In our case the root cause is that the GWT is always focusing on build time optimisations. I had big hopes for UiBinder - and I use it in some cases - but it turns out that this only targets build time. We are uploading schema's so we need to generate big UI's on the fly. Otherwise I would have created a generator that would spit out UiBinder compatible classes/files. But with pure usage of the widgets it just does not scale. Sure if we wait a few more years then everyone will be using IE10 or newer with GPU acceleration and god knows what else, and maybe we won't care that much anymore, but do not forget that mobile phones consume a lot of battery if you do not optimize. GWT started doing similar bulk rendering with the Cell widgets, but there it is a much more narrow context. In tables you can get away with the rubber stamp approach and collect all events centrally. But with forms that becomes a bit more complicated, since I really need exactly the same behaviour as widgets already support, so why not share the code ? David On Tue, Jun 4, 2013 at 10:23 AM, Jens <jens.nehlme...@gmail.com> wrote: > > They way I use the widgets, maybe not supported, work perfectly. It is >> made part of the widget hierarchy. And when I remove the widget, everything >> is again cleaned up. I did a lot of memory leak investigating and it is >> just working the way it should. Even if the window close event is >> triggered, they get properly cleaned up just like the rest of the widget >> hierarchy. >> >> The wrap methods on Widget assume and do too much and that makes them not >> usable beyond the scope of wrapping non nested widgets. >> > > Interesting, then they maybe decide to implement it the safe way so they > don't have to think about that case when they want to change Widget > internals. > > -- J. > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit+unsubscr...@googlegroups.com. > To post to this group, send email to google-web-toolkit@googlegroups.com. > Visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
