Yeah, but my concerns are not as much at that level, but with things more at the low level of how GWT works. Like what I mentioned about how the selection script works to load the application JS code into the iframe, and then execute the bootstrap logic. So I think I'm leaning to have one application instance, always loaded and ready to be invoked by external JS, capable of handling many forms.
I'm already dealing with the complexity of the fact that the application is loaded in a XMLHttpRequest, which poses other challenges to guarantee the canonical bootstrap sequence. On Oct 30, 12:23 pm, Ian Bambury <[email protected]> wrote: > Would it be possible for one GWT app to be included every time (with v2.0 > the initial download can be quite small as it allows you to lazy-load code > chinks as needed with code-splitting). This one app then checks for certain > IDs added by the portlets. If they exist, it does its stuff. > > RootPanel p; > p = RootPanel.get("instance1"); > if(p != null) ... > p = RootPanel.get("instance2"); > if(p != null) ... > > (or a for-next - there are any number of possibilities) > > Ian > > http://examples.roughian.com > > 2009/10/30 Raziel <[email protected]> > > > > > > > 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 <[email protected]> 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 <[email protected]> > > > > > 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 <[email protected]> wrote: > > > > > On 30 oct, 01:15, Raziel <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
