On Mar 24, 11:42 am, Thomas Broyer <[email protected]> wrote: > On Mar 24, 5:09 pm, Nathan Wells <[email protected]> wrote: > > > You're correct, in more complex environments where a more robust > > property provider is necessary, my approach wouldn't do much good. But > > then, I'm not talking about handling those use cases. The goal is to > > not make an unnecessary request, and if I have the user agent in the > > server on the initial request, I know everything that the vanilla > > property-provider uses, unless I'm mistaken. > > > Also, when I was referring to generating the code I was talking about > > at GWT compile time. > > AFAICT, that's why Wave does. If I were to do it (and I guess that's > how they did it), I'd use a @LinkOrder(Order.PRIMARY) linker to > generate a JSP page instead of the *.nocache.js selection script. > Such a linker couldn't be generalized though, it'd have to be specific > to each project:
Could't you generate a general "selection script" JSP and then use an include to get it into whatever page, much the same way the generic nocache.js files work today? I need to do more research on this, but, on it's face, it seems possible. In spite of the location and timing changes of the decision process, it's the same process, with equivalent inputs. different JSP template (could be worked around > though), different deferred binding properties, etc. though in the > simplest case (you don't introduce any new deferred binding property) > it would just work! > ...with the added benefit that you can do conneg on the lang at the > same time, as you have the Accept-Language request header! -- 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.
