HI Well yes, what you have described in the beginning part can be done, so long as Panel A does not communicate with Panel B at compile time, or better said, as long as Panel A does not need/have any references to Panel B.
Essentially you can have the following senario: 1) Framework is built and compiled(This should have the onModuleLoad() method). 2) Framework inherits Panel A like you would a library. (In Framework xml file something like this <inherits name="com.google.gwt.user.User"/> <inherits name="path.to.PanelA.FirstClass"/>(This class should be treated as a "EntryPoint" Class, but should not implement EntryPoint) Then when you're ready to put in Panel B <inherits name="path.to.PanelB.FirstClass"/>(This class should be treated as a "EntryPoint" Class, but should not implement EntryPoint) ) If you have any questions, don't hesitate HTH :) P.S : HTH--->Hope That Helps. On Aug 22, 5:16 pm, Mickey <[EMAIL PROTECTED]> wrote: > Hi HTH, > > If what you are describing does not require Panel A source to build > Panel B, and either or both of these panels can be displayed within a > parent panel/page (without loose integration via frames, etc), then > let's say for the sake of argument, yes. That is close enough to > describe my scenario. > > If that doesn't match your description, then... :) > > Basically, I realize our framework would need to provide some level of > abstraction whereby add-ons would be dynamically defined/configured > externally as menu items/actions/classes within some sort of site map, > controller config file, or whatever you want to call it. The child > classes are pretty much ignorant of one another at the source/class > level, communicating through the framework interface or shared > objects, etc. But they are hosted by a common UI framework. > > Thanks, > Mickey > > On Aug 22, 9:58 am,mon3y<[EMAIL PROTECTED]> wrote: > > > Hi, > > > I'm just trying to understand what it is exactly you want to do.... > > > Lets just say for argument sakes you have a framework that > > accommodates to panels. > > > So what you want to do is develop Panel A and Panel B independently of > > each other, and again for argument sakes, you release with panel A > > only and then the next release put on Panel B on your already existing > > framework? is this correct? > > > And you want to know how to integrate Panel B on your next release? > > > If i'm totally left field on this just reply with a smiley, :) > > If you want to do the above...yes it is possible and there are older > > threads on these forums that will lead you to what you need. > > > HTH > > :) > > > On Aug 22, 3:07 pm, Mickey <[EMAIL PROTECTED]> wrote: > > > > I think one of us is still missing some points (hopefully it's me). So > > > let me try to clarify. > > > > On Aug 21, 3:00 pm, walden <[EMAIL PROTECTED]> wrote: > > > > > > Thanks for the reply. What I mean by "developed independently" is that > > > > > a core UI framework would be built/distributed as a common > > > > > infrastructure, and add-on components would be developed/distributed > > > > > individually to integrate/run on this platform. > > > > > Just like my application builds on the GWT UI classes, no? > > > > Yes, I understand this point, and yes this would work if you are only > > > talking about compiling one component (or as many as source is > > > available for) on top of the base framework module lbrary. But the > > > idea breaks down after that in the same way that I cannot expect to > > > build on top of one of your modules - because I do not have your > > > source. I only have my source and the common library source. > > > > > > So, it is not an > > > > > "application" in the traditional sense. Think more along the lines of > > > > > Eclipse, for example (although I'm sure someone will point out it is a > > > > > bad example). Plug-ins are developed for the Eclipse platform > > > > > independently without much regard for one another. They are only > > > > > interested in meeting the requirements of the framework. They are not > > > > > compiled/distributed together as one big application. Correct? That's > > > > > the idea here. > > > > > If you're thinking "like Eclipse" then maybe you'll be stuck with a > > > > plug-in solution that's not the best fit for what you're actually > > > > doing. > > > > Maybe. > > > > > > We cannot control (or even anticipate) the development schedules of > > > > > these "plug-in" components. They will probably need to be built and be > > > > > targeted to a particular version of our framework, and updates will > > > > > need to be sensitive to backwards compatibilty. But the resulting > > > > > "application" will be any number of permutations of combined > > > > > components all residing within the same core UI platform. It's made up > > > > > of whatever pieces the customer decided to purchase (separately). > > > > > The fact that you still have to package one of those permutations at > > > > some point in order to deploy it is the point I was making earlier. > > > > "Permutations" is not a problem for the GWT compiler, which will > > > > optimize each particular permutation to a better runtime than your > > > > plug-in approach could. > > > > No. The idea is not to "package" these combination together (just as > > > Eclipse plug-in combinations are not packaged together). Plug-ins > > > would be packaged/installed separately and installed into the same > > > base location whereby they become integrated into a cohesive "app". > > > So, effectively the packaging is performed at install time in a > > > cumulative fashion, not beforehand for distribution, because again, > > > the plug-ins may come from different sources. > > > > > > Obviously, GWT cannot do all the plumbing for us that will be > > > > > required. We need to develop our own way of logically stitching things > > > > > together. But it seems that integratation of separately compiled > > > > > modules is not supported very well, if at all. That's what we'd like > > > > > to be able to do. > > > > > I'm not convinced. But good luck. > > > > Well, I've seen enough people here voice similar interest in this type > > > of support. So I do not think I am alone. I was just hoping that > > > someone might have discovered some clever way of overcoming this > > > limitation. > > > > Thanks for the feedback. > > > > > Walden- Hide quoted text - > > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
