I'm late to reply as usual but really appreciate the info. Will likely revise my planned approach along the lines you have indicated to use deferred binding.
On Apr 19, 7:46 pm, Thomas Broyer <[email protected]> wrote: > On 18 avr, 07:42, JohnGunther<[email protected]> wrote: > > > Thanks for the great info, sorry I didn't see your reply till now. > > > I think your first idea would not work in my case because I would have > > to have code that referenced the optional module even if they didn't > > use it (there are "if (usingOptionModule) do this by invoking its > > methods otherwise do something else" kinds of constructs in there) So > > they would always have to include the module anyway, or the compiler > > would complain about the method invocations not being defined? > > Right. > > > I've never used deferred binding before (except what GWT does > > automatically) but had begun to read up on it (Hanson and Tacy's GWT > > in Action and Dewsbury's Google Web Toolkit Applications both cover > > it) after making my post. Your set-property variant seems like it > > would be the nicest for users. I've never compiled anything that had > > multiple variants (say for different browsers) but where I only had > > selected a single one of them...I've always just let GWT crank out all > > the various permutations. The compiler won't complain that the code > > for actually implementing the "value=true" option isn't available if I > > only actually use the "value=false" setting? > > It won't. > > > It just grabs the replace- > > with I actually selected for and ignores the other ones..does not > > attempt to verify that my module is "correct" regardless of the > > specific property setting some specific user may have selected? > > No, it only compiles (and checks) what you tell it to compile. (maybe > the -validateOnly would do it, but wouldn't bet on it) > > > BUT...how can it know before it gets used which properties will be > > specified, so it seems that it must check that all the code for any > > permutation is available, since a module that has a true option and > > associated replace-withs has to provide the code to implement that > > option, too, since someone might use it with true. > > If you call the compiler, it means you're compiling an application, so > checking other permutations would be useless (woudl take time without > any impact on the output; would you like the compiler throwing an > error for something you're actually not compiling?). The compiler > doesn't know about "libraries". > > > That implies I > > somehow have to physically bundle the optional module with my module, > > No. > > > So what I am leaning towards now is defining an ordinary Java > > interface ("IOptionalLibraryObjectFactory") that creates instances of > > the optional library's objects that users of the optional library must > > implement (I tried this, and it does work). If they don't implement > > it, there are no refs to the optional library and I compile without > > error. Problem with this approach (at least the way I've tried it) is > > users end up having to add a good deal of boilerplate Java code to use > > the optional library. > > Try the deferred-binding way and judge by yourself ;-) > > > If you check out chapter 10 of Google Web Toolkit Applications there > > is an example there that maybe would do everything I'd need, but it > > involves actually generating the said boilerplate automatically via > > putting stuff in the rebind folder, "generate-with" clauses, etc. and > > that just seemed like too much work...if it's that hard maybe wiser to > > make the users of my library paste in their own boilerplate and > > concentrate on just making it easy for them to grab that boilerplate? > > Using simple replace-with deferred bindings as I proposed is much > simpler and less error-prone thatn generating code that's probably not > needed... > (just replace your if(useOptionalModule) structures with 2 classes > (the one using the useOptionalModule could eventually inherit the > other) and a replace-with rule; if the class to be split is public, > refactor to use a "helper" internal class and split that one, so that > your users won't have to use GWT.create()) > For best performances, your internal helper classes should be > singletons (private static class, instantiated once only in a private > static final field); the compiler should then inline the helper's > methods and your helper's class won't exist at all in the compiled JS. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
