Hello David, hey folks, we figure exactly the scenario you describe here with our application. It's similar to a portal based application as you describe it.
Basically, what we struggle with: Say we compile the main application with some portlets pre-installed resulting in a single JS file. We also provide additional modules/portlets that the user might want to install. These modules, however, have a completely different lifecycle than the rest of the portal. Now, if we'd compile the additional portlets one by one, wouldn't that result in a whole bunch of duplicated JS code e.g. for JRE emulated classes? Next, the JS code is of course obfuscated so the names of our Java types vary from compilation to compilation. If I'd compile each module separately it wouldn't find any existing class from the portal application. Even worse, I thought it would just duplicate the portal applications classes into the portlet JS code (of course, assuming we have a call dependency to the portal application). The only solution to this problem we currently think of is to trigger a complete re-compilation of the app at runtime. For instance, we try to implement a registry where each module/portlet Jar registers and once the registry detects changes it triggers re-compilation of the complete javascript files. We'd likely do that in a servlet context listener or something equivalent. Has anyone tried something similar already? Has anyone similar problems and/or other solutions? Thanks! On 11 Aug., 14:41, David <david.no...@gmail.com> wrote: > Nathan, > > The use case is indeed not what you think it is. In your case I could > just deliver the main application as a widget library and build the > final application from this jar. > > It is not possible tocompileboth the main application and child > applications in one unit because these are developed by different > groups/companies. The sub applications are installed separately from > the main applications and the main application is updated separately > from the sub applications as well. > > When you create a portal you don't always write/compileall the > portlets that are being deployed. Per installation the version and > type of portlets can also be different so it is just impossible to > deliver everything as one big application. We do not host the service > either, so the portal is delivered as an ear that will allow appserver > admins to configure the installed applications at runtime. So we just > don't know what applications are used and they are not even from our > group/company. > > David > > > > On Tue, Aug 11, 2009 at 12:05 PM, Nathan Wells<nwwe...@gmail.com> wrote: > > > I agree with Ed, but don't know that I fully understand the use > > case... I'm doing a similar thing without iframes or runAsync. > > > Essentially, I created a PresenterMap that extends HashMap<String, > > Presenter> where Presenter is an interface that has an "presentIn > > (HasWidgets)" method. This method does the necessary work to load the > > UI into the given panel (of course, I separate UI-specific concerns > > into "view" classes). What this allows me to do is generate a > > navigation pane that has no knowledge of the underlying pages and can > > be configured for whatever navigation needs a given user/admin has. > > > I know I'm kind of leaving things unclear, but I don't want to go into > > too much detail without understanding your needs. > > > On Aug 11, 3:22 am, Ed <post2edb...@hotmail.com> wrote: > >> Hi All, > > >> Why not use the Async functionality in 2.0? (to lazy load/run the code > >> for the other apps). > >> See:http://code.google.com/p/google-web-toolkit/wiki/CodeSplitting --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
