meta tag applying to just one module?

[Lex Spoon]

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 

[Scott Blum]

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?

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[Lex Spoon]

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

[John Tamplin]

On Tue, Mar 2, 2010 at 2:54 PM, Lex Spoon <sp...@google.com> wrote:

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.

 So, in IFrameTemplate.js for example, the changes would be:

• processMetas() keeps track of which properties it has seen and keeps the most-specific one of each, and ignores any property with :: that doesn't have __MODULE_NAME__ as a prefix
• how would the base URL lookup change?  I don't see that it looks for a meta property anyway, instead using a <base> tag -- are you suggesting adding a check for a meta property instead of / in addition to the <base> tag check?

--
John A. Tamplin
Software Engineer (GWT), Google

[Lex Spoon]

On Tue, Mar 2, 2010 at 3:14 PM, John Tamplin <j...@google.com> wrote:

On Tue, Mar 2, 2010 at 2:54 PM, Lex Spoon <sp...@google.com> wrote:

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.

 So, in IFrameTemplate.js for example, the changes would be:

• processMetas() keeps track of which properties it has seen and keeps the most-specific one of each, and ignores any property with :: that doesn't have __MODULE_NAME__ as a prefix

Yes.

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.

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">

 

• how would the base URL lookup change?  I don't see that it looks for a meta property anyway, instead using a <base> tag -- are you suggesting adding a check for a meta property instead of / in addition to the <base> tag check?

Yes, that's the suggestion.    Function computeScriptBase would be modified to start with the following:

if (__gwt_getMetaProperty('baseUrl')) {
 base = __gwt_getMetaProperty('baseUrl')
 return;
}

Lex

[John Tamplin]

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?

[Lex Spoon]

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

[Scott Blum]

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. :(

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[Lex Spoon]

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

[Scott Blum]

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?

[Lex Spoon]

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

[Scott Blum]

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.

[Lex Spoon]

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.

2. How is this better than using a meta property?  It looks identical except that it inserts a var rather than a <meta> tag.

-Lex

[Scott Blum]

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?

 

 

[Lex Spoon]

"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

[Scott Blum]

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.