jdeferred
Fork for a GWT open-source project
Hi Ray. I've forked the core part of your project to Turbo GWT (Core). I'll use it in the HTTP module, and I had to make a slight change on the AlwaysCalback (instead of just the State, I need a Context with more information). I've kept all the license/credits in the classes and in the main page of the Core project. Turbo GWT is under Apache2 license too. Thanks for your excellent work.
thanks! btw - will there be any chance for us to consolidate the effort and keep the jdeferred-core compatible? it would be awesome if the developer experience is the same regardless of the platform (i.e., plain java, android, and GWT!)
There's a chance for that. And I think it wouldn't be too hard to acomplish the GWT integration. I've already done a time ago, the integration of a Java library with GWT, based on the integration of the Guava project.
For me, the only problem is the change I had to make in the AlwaysCallback. I needed it, but it let the API uglier. =/
Also, I'm using less than one third of the classes, (I don't even support filter!) because I'm experimenting it yet. I need to use it more and know better.
that sounds pretty cool. I'd like to learn more about how I can integrate jdeferred-core w/ GWT. I know someone else had tried it but never contributed the code back =(
I will look into making the callbacks more extensible (or provide ways to extend it).
I'd like to contribute but can not commit myself. Over time I hope to evolve my knowledge of your API, and then get to the point of making the portability.
About the change I've made, I'm not sure it is a good solution yet. But I needed to somehow expose some elements of the HTTP response. So I chose the AlwaysCallback to it. Here's what I did (focus on the Context class and its use): http://growbit.github.io/turbogwt-core/javadoc/apidocs/index.html (see future package) http://growbit.github.io/turbogwt-http/javadoc/apidocs/index.html (see future package)
no worries! I'm just happy that you found this to be a good starting point.
=) since both the resolved object and the rejected object are generics - you can actually use anything that makes sense.
E.g., for the resolved object, you can wrap the context and the result into a single class. In other words, think about what's necessary for either states, and design either classes accordingly. But it's totally up to you.
e.g., deferred.resolve(new Success(context, result))
I had already thought about enveloping the result, although I did not like the idea. But maybe it would be better than modifying the API. I'll try this to get a better feeling.