It's a forms framework where different elements in a complex page (you can call them portlets, or just randomly arranged elements) include forms they wish to render. Given that not all my app is GWT, I cannot nicely control the integration with the forms rendering framework which I'm going to develop in GWT.
I guess an option is just loading the GWT application once, have it available always so when forms need to render the GWT application can just be "called" with the form data and proper information to namespace the rendering; internally the application would handle creating a new separate instance per call to render a form. However I was hoping for a more hmmm traditional approach where the GWT application is loaded as usual: including the nocache.js, and then the application instance is in charge of rendering just one form (as opposed of possibly handling the rendering of many, as with the previous option). But as I said in my last post that doesn't quite work out of the box given that GWT is not quite designed (at least the default selection script) to have many instances in the same page. I understand this is not an ideal GWT app. scenario, but I'm just pondering my options to come up with the best approach. Thanks On Oct 30, 11:37 am, Ian Bambury <ianbamb...@gmail.com> wrote: > Hi Raziel, > > It might help if you explained what the problem is that you are trying to > solve. > > I can't think of any situation where an html page needs more than one GWT > app in it. > > Ian > > http://examples.roughian.com > > 2009/10/30 Raziel <raziel...@gmail.com> > > > > > > > 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 -~----------~----~----~----~------~----~------~--~---
