Hi Thomas, thanks for the links, although like the ticket says they're not very conclusive, and not quite what I'm looking for.
In general I'm thinking through all the considerations I have to keep in mind to build this application which can be injected into the same page, by different and unrelated sections of code. The obvious scenarios, like creating or looking for elements by specific IDs, I'm aware of. When I said "generate IDs for a widget these must be namespaced according to the application's instance that created it" I meant exactly what you said: the application instance has to know, somehow (probably passed from the snipped of code that included it), something that "identifies" it and thus can serve to name-space it and be able to truly generate different IDs to the other instances. My concern is with those things that are not obvious, at least to me. For example: if you end up with code like the one below, generated from unrelated pieces of code, the three nocache scripts will create the exact same selection script named after the module, with the exact same implementation. Thus, by default there will be 3 iframe generated containing the injected JS of the application. That's bad HTML since the iframe tags have an assigned ID equal to the module name, and thus the document will end up with 3 elements with the same ID. But not only that: the selection bootstrap script uses the ID to grab the iframe and call the gwtOnLoad function of the application instance living within. You can see how this would be error prone since there's no guarantee that the right iframe will be obtained. <div id="instance1"> <script src="/blah/blah/myapp.nocache.js"> </div> <div id="instance2"> <script src="/blah/blah/myapp.nocache.js"> </div> <div id="instance3"> <script src="/blah/blah/myapp.nocache.js"> </div> There's not much (if anything) I can do during compile time since the parameters to identify the applications are available only at runtime. Even worst in my case, as I said, the instances (injection snippets) can be done by different unrelated sections of the page. So I have to figure out how to parameterize the selection script with the runtime values it needs to 1) uniquely identify the script to avoid calling one of the exposed function on the wrong script 2) put different IDs to the iframes 3) obtain the right iframe using the right ID. So this calls for a new primary linker to change the bootstrap logic. The main issue being how the script should retrieve the runtime values (since there's no central place that can provide them). Anyway, that's my specific problem, but I'm wondering if there are other considerations I should be aware of. Thanks On Oct 29, 9:20 pm, Thomas Broyer <t.bro...@gmail.com> wrote: > On 30 oct, 01:15, Raziel <raziel...@gmail.com> wrote: > > > Hi, I have a legacy application and thus I'm migrating to GWT by > > reimplementing parts of it at a time. However, one of this "parts" may > > appear in a document more than once, displaying different information. > > > Aside from ensuring that if I generate IDs for a widget these must be > > namespaced according to the application's instance that created it (in > > case I retrieve them by ID somewhere), are there any other precautions > > that I should take to avoid collisions between application instances? > > For example, since the GWT application is put inside an iframe whose > > id is the name of the application's module, shouldn't it be necessary > > to generate the iframes with different ids? Otherwise we'll end up > > with elements (the iframes) with the same ID. > > If you included the very same JS script, why would it run differently > than the previous one? I mean, you use RootPanel.get(XXX) or > Document.get().getElementById(XXX) somewhere in your app; and XXX > cannot be different for 2 "instances" of the same app in the page > (it's either hard-coded or taken from the same Dictionnary –whose name > is hard-coded– or the URL), right? > > If you want your app to appear more than once, in different > "containers" of the same page, you'd have to use a Dictionnary or > similar to pass the containers' IDs to the app, and the app loops > through the list to instantiate as many "root components" as > necessary. > Seehttp://groups.google.com/group/Google-Web-Toolkit-Contributors/browse... > andhttp://code.google.com/p/google-web-toolkit/issues/detail?id=2592 > > Or am I misunderstanding you? --~--~---------~--~----~------------~-------~--~----~ 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-web-toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
