Actually, I'd be surprised if the dependancy injection implementation
doesn't boil down to a form of deferred binding in the end for performance
reasons (except using the Generators mechanism instead of explicit deferred
binding).
On Tue, Apr 14, 2009 at 5:24 AM, Thomas Broyer t.bro...@gmail.com
On 10 avr, 17:52, Yves yves.cuillerd...@gmail.com wrote:
Hello
Reading the documentation for the module xml files, i just realize
that the tag replace-with .../ allows for dependency injection.
How that?!
Suppose i need to use different class implementation depending on my
environment
On 14 avr, 11:42, Vitali Lovich vlov...@gmail.com wrote:
Actually, I'd be surprised if the dependancy injection implementation
doesn't boil down to a form of deferred binding in the end for performance
reasons (except using the Generators mechanism instead of explicit deferred
binding).
Why not use Google GIN for your dependency injection needs:
http://code.google.com/p/google-gin/. It's a Guice implementation on
the client side. We're using it on a large project and it's working
out really well.
You can also use GWTMockUtilities.disarm(); to mock out GWT widgets.
--
Arthur
Sweet - that's a clever approach.
On Sat, Apr 11, 2009 at 1:26 AM, Adam T adam.t...@gmail.com wrote:
Vitali, you'd just create your own property with two values:
Generically:
1. Define the properties:
define-property name=prod.status values=production,test/
2. Define a property
Nice thanks for pointing out
-- Ed
On Apr 11, 8:06 am, Vitali Lovich vlov...@gmail.com wrote:
Sweet - that's a clever approach.
On Sat, Apr 11, 2009 at 1:26 AM, Adam T adam.t...@gmail.com wrote:
Vitali, you'd just create your own property with two values:
Generically:
1. Define
Hello
Reading the documentation for the module xml files, i just realize
that the tag replace-with .../ allows for dependency injection.
Suppose i need to use different class implementation depending on my
environment (real class for production, mock for development ...). I
just have to have
Nope. In fact, it's even more powerful because you can put in complex
conditionals. Ideally, you wouldn't even need to files because you could
just pick 1 class when in production, 1 class when in development, but that
selection would still be in a single Foo.gwt.xml.
Also, you may find it
On Sat, Apr 11, 2009 at 12:50 AM, Vitali Lovich vlov...@gmail.com wrote:
Nope. In fact, it's even more powerful because you can put in complex
conditionals. Ideally, you wouldn't even need to files because you could
just pick 1 class when in production, 1 class when in development, but that
Vitali, you'd just create your own property with two values:
Generically:
1. Define the properties:
define-property name=prod.status values=production,test/
2. Define a property provider; for example as simple one as folows:
property-provider name=prod.status
