On Sat, Nov 24, 2012 at 9:44 PM, 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. > No, making i18n work in .shared. isn't done yet -- I have the next phase of the work mostly done, but it will probably be the Christmas break before I can finish it up. LocaleInfo will get fixed in that step, but there are still more steps to make everything work on the server. HasDirection is somewhat weird, as it is implemented by widgets but there isn't anything client-specific about it. Arguably, you could either move just Direction into .shared. as that part is fine to use on the server, or you could move the whole interface there as there isn't actually anything client-specific about it (you might even imagine model objects implementing it). -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
