On Mar 25, 12:03 pm, Nathan Wells <[email protected]> wrote: > 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.
Hmm, right. The thing is: how would you "plug" your server-side property-providers in? An ideal such linker would even allow you to split the selection between server-side and client-side, but maybe soft permutations would be a solution to this "issue". -- 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.
