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?
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 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?
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. That implies I
somehow have to physically bundle the optional module with my module,
something I'm trying to avoid.
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.
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?
John
On Apr 6, 10:21 am, Thomas Broyer <[email protected]> wrote:
> On 6 avr, 04:31, JohnGunther<[email protected]> wrote:
>
>
>
> > Sorry, for late reply, I just saw your post.
>
> > I think you are correct. But, my goal is to eliminate the need for
> > users to physically add the extra JAR file associated with the
> > optional library to their project (unless they need the optional
> > features it provides).
>
> > What I want is:
>
> > o Just 1 JAR distributed by me.
> > o Code for optional library in separate JAR distributed/maintained
> > by others
> > o Users of my library don't have to physically mess with the
> > optional JAR (no need to
> > download it, place it on build path, or add an inherits clause) if
> > they don't use those
> > optional features in their code.
>
> > Ideally, my code might even somehow check if the optional library is
> > available. If so, it uses it, otherwise it uses the built-in fallback.
> > But it would be OK if the developer using my library would just tell
> > it if the optional library is to be used or not.
>
> Can't you put those optional features into another module that
> developers would only inherit if they want to (and thus would have to
> pull the third-party JAR and put it in the classpath only when opting-
> in)?
>
> If you don't want (or can't, for whichever reason) separate the
> optional features in a distinct module, than you can use deferred-
> binding; and opting-in could be either:
> - inheriting another module containing the appropriate <replace-with>
> mappings
> - setting a property (<set-property>) to a specific value (this
> property having been set to a "default" value in your module) which
> would trigger different <replace-with> rules (all in the same module),
> e.g. your module contains (along with all the needed <generate-with>
> mappings) <define-property name="use.optional.features"
> values="true,false"/><set-property name="use.optional.features"
> value="false"/>, and the developer opts in by adding this line to his
> module: <set-property name="use.optional.features" value="true"/>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
