On Sun, Nov 25, 2012 at 3:44 AM, Thomas Broyer <t.bro...@gmail.com> wrote: > On Thu, Nov 22, 2012 at 4:22 PM, John A. Tamplin <j...@jaet.org> wrote: >> It should be the case >> that if you ever see server code referencing client classes it is an error, >> and if we leave things like this around then we won't ever get away from it. > > Another place where server code (shared code actually) references > client code is I18N: at least c.g.g.i18n.shared.Bidi* classes > reference c.g.g.i18n.client.LocaleInfo and HasDirection.Direction; > there might be others. Have the Bidi* classes mistakenly been put in > shared instead of client, or was the client → shared move incomplete, > or should the Bidi* classes have been split in shared vs. client APIs? > I currently have no idea how/where to split I18N into > client/shared/server JARs.
…and c.g.g.dom.builder.shared.ElementBuilderBase referencing c.g.g.com.client.Element. (maybe an ElementBuilderBase should have been created in client that extends the one in shared and adding the finish() method, and similarly for HtmlElementBuilderBase and HtmlBuilderImpl; on the other hand, as long as you don't call finish() on the server-side you're safe, right? –I have a few gaps in my classloading understanding; I quickly tested safehtml's UriUtils without c.g.g.http.client.URL and it worked, unless I messed up my test–). -- Thomas Broyer /tɔ.ma.bʁwa.je/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
