Re: Easiest way to package a library with optional features requiring a sub-library?
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 wrote:
> On 18 avr, 07:42, JohnGunther 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 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
-~--~~~~--~~--~--~---
Re: Easiest way to package a library with optional features requiring a sub-library?
On 18 avr, 07:42, John Gunther 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 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
-~--~~~~--~~--~--~---
Re: Easiest way to package a library with optional features requiring a sub-library?
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 wrote:
> On 6 avr, 04:31, JohnGunther 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
> mappings
> - setting a property () to a specific value (this
> property having been set to a "default" value in your module) which
> would trigger different rules (all in the same module),
> e.g. your module contains (along with all the needed
> mappings) values="true,false"/> value="false"/>, and the developer opts in by adding this line to his
> module:
--~--~-~--~~~---~--~~
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
Re: Easiest way to package a library with optional features requiring a sub-library?
On 6 avr, 04:31, John Gunther 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 mappings - setting a property () to a specific value (this property having been set to a "default" value in your module) which would trigger different rules (all in the same module), e.g. your module contains (along with all the needed mappings) , and the developer opts in by adding this line to his module: --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Easiest way to package a library with optional features requiring a sub-library?
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. I think that if my code contains explicit references to the external library, the GWT compiler will complain about classes that don't exist (even if users of my library never call that code) unless that optional JAR is on the build path, etc. The fact that the compiler may eliminate the dead code in the end doesn't eliminate the hassle of having to add a JAR you are not using to your build path, etc. just to make the compiler happy. I realize this is a relatively small hassle but every little bit helps. I don't want to just bundle the code from the optional library into my JAR (as I've seen some projects do) because I can't control when the optional library guys release their next version, and don't want to release a new version of my library every time they do. John On Mar 15, 8:10 pm, Vitali Lovich wrote: > I may not be understanding your question. GWT will compile your code into > whatever Javascript is actually used. > > So when GWT compiles your user's code, if they don't use the parts that rely > on the optional library, they won't get that library automagically, AFAIK, > by the GWT compiler recognizing this. > > Caveat: The inherits stuff in the module configuration might still cause > code to be compiled, but the dead-code elimination in the compiler should > cause it to not be included in the result, thus your user's code should have > those optional libraries omitted. If you care about compilation-speed, > you'd have to have the user edit your gwt.xml file to include only the > modules used by your code they rely on. > > Perhaps someone more familiar with the internals of the gwt compiler can > comment as to whether or not my explanation is correct or way off base. > > On Sun, Mar 15, 2009 at 12:28 AM, John Gunther > wrote: > > > > > Is it possible to release a GWT library that has optional features > > that require an additional library (written by someone else, packaged > > in a module JAR) but that does not require its users to load that > > additional library if they don't need the optional features? > > > What is the best way to do this that results in users of the library > > having the least number of steps to configure it with or without the > > optional features? > > > John > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Easiest way to package a library with optional features requiring a sub-library?
I may not be understanding your question. GWT will compile your code into whatever Javascript is actually used. So when GWT compiles your user's code, if they don't use the parts that rely on the optional library, they won't get that library automagically, AFAIK, by the GWT compiler recognizing this. Caveat: The inherits stuff in the module configuration might still cause code to be compiled, but the dead-code elimination in the compiler should cause it to not be included in the result, thus your user's code should have those optional libraries omitted. If you care about compilation-speed, you'd have to have the user edit your gwt.xml file to include only the modules used by your code they rely on. Perhaps someone more familiar with the internals of the gwt compiler can comment as to whether or not my explanation is correct or way off base. On Sun, Mar 15, 2009 at 12:28 AM, John Gunther wrote: > > Is it possible to release a GWT library that has optional features > that require an additional library (written by someone else, packaged > in a module JAR) but that does not require its users to load that > additional library if they don't need the optional features? > > What is the best way to do this that results in users of the library > having the least number of steps to configure it with or without the > optional features? > > John > > > > > > > > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Easiest way to package a library with optional features requiring a sub-library?
Is it possible to release a GWT library that has optional features that require an additional library (written by someone else, packaged in a module JAR) but that does not require its users to load that additional library if they don't need the optional features? What is the best way to do this that results in users of the library having the least number of steps to configure it with or without the optional features? John --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
