Determining Permutation on Server
Nathan Wells
send on the server rather than the client? What I'm thinking is that
you could eliminate the need for the selector script entirely if you
had a smart enough server. You could even auto generate the code using
a linker, I would think.
So, is there a reason why you wouldn't want to do it?
Ian Bambury
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Nathan Wells
result? I guess I'm not clear on the intricacies of how each browser
would handle this, but you could keep track of whether the app was
modified on the server. If it hasn't been modified, then send 304.
Or am I missing something?
On Mar 23, 9:25 am, Ian Bambury <ianbamb...@gmail.com> wrote:
> How would you determine if the current code had been cached on the client or
> not?
>
> Ian
>
> http://examples.roughian.com
>
> On 23 March 2010 14:41, Nathan Wells <nwwe...@gmail.com> wrote:
>
>
>
> > Is there a reason you wouldn't want to determine which permutation to
> > send on the server rather than the client? What I'm thinking is that
> > you could eliminate the need for the selector script entirely if you
> > had a smart enough server. You could even auto generate the code using
> > a linker, I would think.
>
> > So, is there a reason why you wouldn't want to do it?
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Google Web Toolkit" group.
> > To post to this group, send email to google-we...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
mmoossen
great idea, i think caching has to be handled carefully but there
should not be any stoppers.
Michael
Olivier Monaco
How do you determine the right permutation for the client? Using the
User-Agent? What if I change it? How to provide custom property-
provider?
An example: we wrote a GWT/SVG library that use svgweb on browser not
supporting SVG. We have a property-provider that determine if the
browser support SVG using the JavaScript method
"document.implementation.hasFeature". There's no way to do it on
server.
Next, code can't be on-fly-generated because ~some~ compilation can
take more than 30 seconds, even for just on permutation.
Olivier
Nathan Wells
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.
Thomas Broyer
On Mar 24, 5:09 pm, Nathan Wells <nwwe...@gmail.com> 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: 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!
Nathan Wells
On Mar 24, 11:42 am, Thomas Broyer <t.bro...@gmail.com> wrote:
> On Mar 24, 5:09 pm, Nathan Wells <nwwe...@gmail.com> 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.
Thomas Broyer
On Mar 25, 12:03 pm, Nathan Wells <nwwe...@gmail.com> wrote:
> On Mar 24, 11:42 am, Thomas Broyer <t.bro...@gmail.com> wrote:
>
> > On Mar 24, 5:09 pm, Nathan Wells <nwwe...@gmail.com> 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".