Re: [gwt-contrib] meta tag applying to just one module?
On Fri, Mar 5, 2010 at 12:28 PM, Lex Spoon sp...@google.com wrote: On Thu, Mar 4, 2010 at 5:16 PM, Scott Blum sco...@google.com wrote: Straw man let's say when you inject a GWT selection script, you can add a single line at the very top: var moduleBaseURL = w00t/ Then at the top of computeScriptBase(), we just look to see if moduleBaseURL is already defined, and if so we return that. 1. That doesn't solve the problem. The problem is that different modules need different base URLs. You'd inject a different var declaration at the top of each inlined script. 2. How is this better than using a meta property? It looks identical except that it inserts a var rather than a meta tag. Seems conceptually simpler, and doesn't introduce the idea of module-specific meta props. Also should be faster since it means less DOM crawling during startup? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] meta tag applying to just one module?
Seems conceptually simpler, and doesn't introduce the idea of module-specific meta props. Also should be faster since it means less DOM crawling during startup? Do you think any of these are blocking problems? In particular, if we went with the 7-line meta-prop solution, would users be harmed in any measurable way? -Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] meta tag applying to just one module?
They are both viable, I'm sure. But all else being equal, we want the simpler thing. My opinion is that the meta-prop thing is more complicated. It adds a new feature (module-specific meta props). It's also not obvious whether the meta-prop should be respected or ignored when the selection script is NOT inlined. But, this is just my opinion, and I understand that you and others might have a different opinion. On Fri, Mar 5, 2010 at 1:35 PM, Lex Spoon sp...@google.com wrote: Seems conceptually simpler, and doesn't introduce the idea of module-specific meta props. Also should be faster since it means less DOM crawling during startup? Do you think any of these are blocking problems? In particular, if we went with the 7-line meta-prop solution, would users be harmed in any measurable way? -Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] meta tag applying to just one module?
On Tue, Mar 2, 2010 at 6:23 PM, Scott Blum sco...@google.com wrote: Meh. I've always thought our selections scripts were too big and complicated as is. I'd rather we could figure out a way to get rid of meta properties altogether. :( That may be, but do we have the time for it? Such a project would easily take a couple of weeks. Would you object, Scott, to extending the existing system for now? It's a two-hour job once we decide on a convention. -Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] meta tag applying to just one module?
It seems like to me, if you have any kind of process for inlining a selection script into a host page, that that process *ought* to be able to update the module base URL correctly. I mean... if you have to generate the correct meta tag to do the exact same thing, while not just modify the selection script being inlined? It seems to me that would avoid extra load-time overhead and complication, and we wouldn't have to extend meta props to work on a per-module basis. Am I crazy? On Thu, Mar 4, 2010 at 12:24 PM, Lex Spoon sp...@google.com wrote: On Tue, Mar 2, 2010 at 6:23 PM, Scott Blum sco...@google.com wrote: Meh. I've always thought our selections scripts were too big and complicated as is. I'd rather we could figure out a way to get rid of meta properties altogether. :( That may be, but do we have the time for it? Such a project would easily take a couple of weeks. Would you object, Scott, to extending the existing system for now? It's a two-hour job once we decide on a convention. -Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] meta tag applying to just one module?
On Thu, Mar 4, 2010 at 12:47 PM, Scott Blum sco...@google.com wrote:
It seems like to me, if you have any kind of process for inlining a
selection script into a host page, that that process *ought* to be able to
update the module base URL correctly. I mean... if you have to generate the
correct meta tag to do the exact same thing, while not just modify the
selection script being inlined? It seems to me that would avoid extra
load-time overhead and complication, and we wouldn't have to extend meta
props to work on a per-module basis. Am I crazy?
Can you give more detail on what you are thinking people should do?
The way the selection scripts currently are, such a rewriter would be
brittle. What the rewriter would need to do is recognize our
computeScriptBase() function and replace it with its own logic. I don't see
a way to do that that won't easily break the next time we tweak our
selection script. So, it seems we'd need to develop a less fragile way to
do rewrites of selection scripts. I can imagine several ways to do that,
but they would all require a substantial, multi-week effort.
To contrast, the running proposal would need ~7 lines of code. Here's the
meta tag part:
name = name.replace(__MODULENAME__::, );
if (name.indexOf(::) = 0) {
continue;
}
Here's the base URL change:
if (base = getMetaProp(baseUrl)) {
return;
}
Lex
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] meta tag applying to just one module?
Straw man let's say when you inject a GWT selection script, you can add
a single line at the very top:
var moduleBaseURL = w00t/
Then at the top of computeScriptBase(), we just look to see if moduleBaseURL
is already defined, and if so we return that.
On Thu, Mar 4, 2010 at 3:31 PM, Lex Spoon sp...@google.com wrote:
On Thu, Mar 4, 2010 at 12:47 PM, Scott Blum sco...@google.com wrote:
It seems like to me, if you have any kind of process for inlining a
selection script into a host page, that that process *ought* to be able to
update the module base URL correctly. I mean... if you have to generate the
correct meta tag to do the exact same thing, while not just modify the
selection script being inlined? It seems to me that would avoid extra
load-time overhead and complication, and we wouldn't have to extend meta
props to work on a per-module basis. Am I crazy?
Can you give more detail on what you are thinking people should do?
The way the selection scripts currently are, such a rewriter would be
brittle. What the rewriter would need to do is recognize our
computeScriptBase() function and replace it with its own logic. I don't see
a way to do that that won't easily break the next time we tweak our
selection script. So, it seems we'd need to develop a less fragile way to
do rewrites of selection scripts. I can imagine several ways to do that,
but they would all require a substantial, multi-week effort.
To contrast, the running proposal would need ~7 lines of code. Here's the
meta tag part:
name = name.replace(__MODULENAME__::, );
if (name.indexOf(::) = 0) {
continue;
}
Here's the base URL change:
if (base = getMetaProp(baseUrl)) {
return;
}
Lex
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] meta tag applying to just one module?
On Mon, Mar 1, 2010 at 3:55 PM, Scott Blum sco...@google.com wrote: Avoiding the larger issue of meta tags applying globally, I'd think for this case there should be a more direct way to do it. What I mean is, you have to load the *.cache.html files from *somewhere*. So (from the inlined selection script), you have to do something roughly equivalent to: iframe.src = baseUrl + strongHash + .cache.html It seems like... whatever process is used to inline the selection script in the first place, has to be able to specify the base URL, at least relative to the host page base url. Am I understanding this right? That's right. It would also be possible to modify the server-side support for inlining the script. However, barring other changes, that would mean people are doing regex rewrites on our selection scripts, which seems rather brittle. The meta property system looks like a good, clean solution. All we need to do is decide on a convention for having them be module-specific. I don't know the history of this feature or what all it is intended to support, but it looks awfully straightforward to allow prepending moduleName:: before the property name. Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] meta tag applying to just one module?
On Tue, Mar 2, 2010 at 3:31 PM, Lex Spoon sp...@google.com wrote: What would most specific be? I was thinking the last meta tag with any given name would be the one that counts. That's what the existing meta-processing code does. So, the following would mean the per-module instance is never used, right? meta name=gwt:property value=org.example.Foo::bar=.../ meta name=gwt:property value=bar=.../ I suppose that could work, but it makes more sense to me to say that the module-specific one is used in that module regardless of the ordering. Looking at that code, I just realized that my example was wrong. It would actually be like this: meta name=gwt.property value=com.google.gwt.sample.mail.Mail::baseUrl= http://static-content.service.com/mail; Ok, so only the value of gwt.property values would be scoped, no other GWT metas? For example, you would not be able to have separate onLoadErrorFn's per module? -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] meta tag applying to just one module?
Meh. I've always thought our selections scripts were too big and complicated as is. I'd rather we could figure out a way to get rid of meta properties altogether. :( On Tue, Mar 2, 2010 at 5:46 PM, Lex Spoon sp...@google.com wrote: On Tue, Mar 2, 2010 at 3:35 PM, John Tamplin j...@google.com wrote: So, the following would mean the per-module instance is never used, right? meta name=gwt:property value=org.example.Foo::bar=.../ meta name=gwt:property value=bar=.../ I suppose that could work, but it makes more sense to me to say that the module-specific one is used in that module regardless of the ordering. It would be nice. However, this is code that will be downloaded to the browser, so it seems we should make sure it's paying its weight. In this case, the desired effect can be achieved by rearranging the meta tags. Given that, last-one-wins seems like a simple rule that would support all the use cases. Looking at that code, I just realized that my example was wrong. It would actually be like this: meta name=gwt.property value=com.google.gwt.sample.mail.Mail::baseUrl= http://static-content.service.com/mail; Ok, so only the value of gwt.property values would be scoped, no other GWT metas? For example, you would not be able to have separate onLoadErrorFn's per module? Good point. I simply hadn't thought about anything but gwt.property. If the module goes with the name attribute, then it would apply to all GWT meta tags, not just the meta property ones. It would look like this: meta name=com.google.gwt.sample.mail.Mail::gwt.property value=baseUrl=http://static-content.service.com/mail; What do people think about this version? Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] meta tag applying to just one module?
The meta tag system is a general system for a host page to influence a loaded GWT module. One aspect I don't understand, however: is there an existing way to have it apply to just one module, if multiple GWT modules are loaded on the same page? The reason this comes up is that I would like to make the magic base URL be settable by the host page for people who have inlined the selection script into the host page. For such people, the built-in magic can do the wrong thing. The first idea that was suggested was to use a meta tag. However, wouldn't t hat by default apply to all GWT apps loaded on the page? It might be that one app comes from one server and the other from a different one. If there is no other idea around, then perhaps we could bake the module into the name parameter, like this: meta name=com.google.gwt.sample.mail.Mail::baseUrl content= http://static-content.service.com/mail; If no :: is present, then the setting applies to every module. Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] meta tag applying to just one module?
Avoiding the larger issue of meta tags applying globally, I'd think for this case there should be a more direct way to do it. What I mean is, you have to load the *.cache.html files from *somewhere*. So (from the inlined selection script), you have to do something roughly equivalent to: iframe.src = baseUrl + strongHash + .cache.html It seems like... whatever process is used to inline the selection script in the first place, has to be able to specify the base URL, at least relative to the host page base url. Am I understanding this right? On Mon, Mar 1, 2010 at 12:38 PM, Lex Spoon sp...@google.com wrote: The meta tag system is a general system for a host page to influence a loaded GWT module. One aspect I don't understand, however: is there an existing way to have it apply to just one module, if multiple GWT modules are loaded on the same page? The reason this comes up is that I would like to make the magic base URL be settable by the host page for people who have inlined the selection script into the host page. For such people, the built-in magic can do the wrong thing. The first idea that was suggested was to use a meta tag. However, wouldn't t hat by default apply to all GWT apps loaded on the page? It might be that one app comes from one server and the other from a different one. If there is no other idea around, then perhaps we could bake the module into the name parameter, like this: meta name=com.google.gwt.sample.mail.Mail::baseUrl content= http://static-content.service.com/mail; If no :: is present, then the setting applies to every module. Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
