On 18 avr, 07:42, John Gunther <[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
-~----------~----~----~----~------~----~------~--~---
