Closed GoogleCodeExporter closed 9 years ago
I think is time to move away from Suco to the more efficient, less verbose,
google powered gin library for dependency injection. I want to start a
discussion of how can be done in a good backwards compatible way.
Suco provides two different areas of services: dependency injection and events.
The change will replace dependency injection with gin and the event-related
classes with the HandlerRegistration gwt's built-in class (and implementing an
event bus instead of lot of little listener collections).
1. General approach
The suggested approach will be deprecate all Suco related classes and promote
the use of new methods. This has big impact over the listeners. In order to
provide backward compatibility a copy of modified Suco classes will be shiped
inside the emite-library so the suco library will be no longer necessary. This
modified classes will have the same functionality than before, but using the
new gin/HandlerRegistrarion infrastructure.
2. Dependency injection
The module system of gin is completely different from suco, so I think it wont
be easy (or probably impossible) to keep backwards compatibility when creating
new modules (so modules should have to be refactored to the gin way of IoC)
Also, other big difference from Suco is that gin doesn't use container
explicitly. That means that you won't be able to add new instances for
injection at runtime class (I think its a minor problem).
The principal methods of the Suco facade will remain the same (Suco.getInstance
and Suco.getProvider) but a automatic-gin-injection will be promoted.
3. Event and Listeners
Since version 1.5 (I think) gwt comes with HandleRegistration class that makes
easy to implement EventBuses and ListenerCollections. Is the same class that
uses the Widgets to fire its events.
The impact of move to HandlerRegistration is BIG, because we will have to
change EVERY listener in our code. The good news is that is quite easy to
maintain backward compatibility wrapping the new classes with the old interface.
4. Conclusion
I think gin is much better IoC library than Suco and move to it worth the
effort. Probably generated code will be smaller and for sure will be faster. I
think it will be a future investment.
What do you think?
Original comment by danigb
on 9 Jun 2010 at 3:52
I've started this issue, but using my own github account (in order to use
better branching git provides).
You can take a look (and ask for write access at:
http://github.com/danigb/emite-library)
Original comment by danigb
on 15 Jun 2010 at 2:58
Good news!
What progress of this issue? Maybe i could help with, since i don't want to
introduce dependency from SuCo in addition to gin one in my project. So what is
most actual version for now? Your git one or svn one?
Thanks.
Original comment by akso...@gmail.com
on 24 Aug 2010 at 8:54
We are in the process of moving, but is not easy. Suco has two
functionallities: IoC and event handling. We are in the process of replace the
old event handling mechanism for the a new one (using the standard GwtEvent and
EventHandler types). This process is NOW in progress and you can collaborate:
while the main core and im packages support both the old and the new system,
the xep extensions don't.
Change the dependency injection is more tricky, specially you have to be
careful to Container events and custom scopes (two feature that gin doesn't
provide). EmiteCoreModule is a good class to look at...
The resume: I'm currently working on that :)
Original comment by danigb
on 24 Aug 2010 at 9:00
Maybe it's a good idea to create a gin module in your project using the Suco
object and then remove that module when emite is gin ready ;)
Original comment by danigb
on 24 Aug 2010 at 9:01
Thanks, should i look into svn or git repo?
Original comment by akso...@gmail.com
on 24 Aug 2010 at 9:41
All in the svn repo ;)
Original comment by danigb
on 24 Aug 2010 at 9:45
This issue will be related only to emite-library. I will add another issue for
the Hablar UI.
Original comment by danigb
on 7 Sep 2010 at 1:23
This issue was closed by revision r1629.
Original comment by danigb
on 8 Sep 2010 at 12:00
Original issue reported on code.google.com by
danigb
on 20 Jan 2010 at 6:12