Closed darscan closed 11 years ago
@creynders Let's try to get this thing released in the next couple of days. I'd like to identify the things that we can leave out for the initial release, and the things that absolutely must be done to ensure non-breaking API changes later.
Looking at the current state of the issues list I'd say that switching to a Promise based lifecycle mechanism is the one thing that will certainly break the current API. As such I'd like us to focus on it if possible.
IMO the current inter-modular communication method definitely needs to be changed before release. Problem is, I'll be hanging out with my kid and missus the next 4 days (very long weekend here in Belgium), with very little time to spend on RL.
Ah yes, true! Have a great long weekend :)
So, it seems all we have left is: Config post processing and MediatorMap conformance. Oh, and maybe a review of the LocalEventMap..
We probably need to push another beta asap - the IInjector change is probably the most backwards breaking change we've introduced in a while. Anything else we should try sneak in for b8?
Can't think of anything! I got the little Commandpayloadf*cker in, so I'm happy ;)
On Tuesday, June 4, 2013, Shaun Smith wrote:
We probably need to push another beta asap - the IInjector change is probably the most backwards breaking change we've introduced in a while. Anything else we should try sneak in for b8?
— Reply to this email directly or view it on GitHubhttps://github.com/robotlegs/robotlegs-framework/issues/107#issuecomment-18921714 .
Sent from Gmail Mobile
Wait, maybe I should push the getProviderFor
first? No?
Not yet. I think we should try get Swiftsuspenders into the RL org first.
Some minor points:
mvcsBundle.Command
and Mediator
shouldn't they be moved to a impl
package?DirectCommandMapExtension
into the MVCSBundle?LocalEventMapExtension
matching
package? It looks so ... orphaned ...Actor
into MVCSBundle ?About 4. I think I'd like it better if it's in robotlegs.bender
or robotlegs.bender.framework
I think i don't need a Actor
. The IEventDispatcher
is more flexible.
Good points.
matching
package. The thing is that nothing inside the framework depends on the "advanced" matching stuff. The framework itself has a much simpler matching API.Actor
hid the fact that anything can be an "Actor". My hope is that by removing it people will learn that their Model and Services don't have to be sub-classes and can just have dependencies injected as usual.1/ Symmetry? Cleaner? It's more clear what the installation fixture is?
2/ It is functionality that existed in v1: CommandMap#execute
, CommandMap#detain
and CommandMap#release
4/ That doesn't matter IMO; the framework
facilitates. It would only matter if we'd plan on releasing the framework package as a separate swc/rsl.
5/ Yeah, I hear you. I just anticipate the question and also, it does provide some convenience with event dispatching.
1/ But I like how it currently looks. Symmetry be damned ;) No, I'm just kidding. Still, I think it's ok. I could be convinced.
2/ True that, lets bring it in.
4/ I can not be convinced.
5/ Hmm.. I could be convinced.
1/ [...] I could be convinced.
But HOW? For the love of God, how?! Tell me! No, it's ok I suppose.
4/ how 'bout bribes? I have a lovely cuckoo clock that will make you the life of the party at any Oktoberfest inspired soiree.
It would be good to actually release this thing!