As I said, I'm not using DSL right now, I'm trying to create a simple hello world base on the Hello World example, it looks everything works fine except that I get runtime error the my injected "model is undefined", I think it because my module and my view need to be under a context this is my current code:
Main.hx
class Main {
static function main() {
var view = new HelloWorldView();
var module = new HelloWorldModule(view);
module.initialize();
}
}HelloWorldController.hx
class HelloWorldController implements ICommandTrigger implements IHelloWorldController {
@inject
var model:IHelloWorldModel;
public function sayHello(who:String) {
// This line makes a runtime error "this.model is undefined"
model.setMessage("Hello $who");
}
}How can I insert the view and the module into a context?
and for the second question... I think the problem is that the Inject metadata should be with uppercase "I" otherwise it's not processed by the reflection builder. If you're using the exactly same module as it's in the hello world repository to model and controller are properly mapped so there shouldn't be any issue with the way you're initializing things
Thanks, I'm hope that you did well in yours vacation!
This was the problem :\
I struggled with that till you answered to me and I thought that it isn't working because the module and the view should be in some context like in the .flow files. why in flow files they start with:
This was the problem :\
I struggled with that till you answered to me and I thought that it isn't working because the module and the view should be in some context like in the .flow files. why in flow files they start with:
@context( name = 'applicationContext' ) {why this line is necessary?
module have it's own context? injector?
the
in theory the HelloWorld example could be created completely without the module class because that one only maps things into its internal injector and connects listeners... the only thing that's currently not possible to do without the module class is to deal with the events (the
@context is to provide scope for the "application" (where application is a very vague term) - this block basically represents the same thing as a root node in XML DSL and it creates ApplicationContext but it can be used just the same as a module (both module and application context implement the same interface IContextOwner which exposes injector)... so to answer the second question - both module and context have injector, both have things mapped into the injector but they serve slightly different purpose... even though sometimes they can be used interchangeably (and there is a plan to allow that for more cases)in theory the HelloWorld example could be created completely without the module class because that one only maps things into its internal injector and connects listeners... the only thing that's currently not possible to do without the module class is to deal with the events (the
override function _onInitialisation() part) but that could be achieved by simply calling the controller directly from the Main class
BTW: I encounter an interesting issue, when I'm trying to open popup in service that triggered by user click the browser(FireFox) block to popup, probably because there is some code after the click and the browser don't understand that the user is clicked for the popup. did you encounter that?
The general rule is that popup blockers will engage if window.open or similar is invoked from javascript that is not invoked by direct user action. That is, you can call window.open in response to a button click > without getting hit by the popup blocker, but if you put the same code in a timer event it will be blocked. Depth of call chain is also a factor - some older browsers only look at the immediate caller, newer
browsers can backtrack a little to see if the caller's caller was a mouse click etc. Keep it as shallow as you can to avoid the popup blockers.
in sense module inside a context is a context inside a context, yes... essentially both things are doing the same thing - providing scope, they both have injector and they both maintain set of instances that are wired together... in the end this is a matter of taste and it also depends on the way you want to use the DSL... for example you could do:
- Single application context that contains modules which contain functionality
or
- Single application context that contains modules which contain functionality
- Single application context which contains other contexts which contain functionality because many times all you need is to expose some controllers API and wire it to another controller which you can do in the main context... basically you can decide to treat the flow file as a module definition
about the popup problem... I know that this is happening in browsers for years now but afaik I never encountered it but that's given by the nature of the projects I work on... the hexMachinas main user is single page app (although complicated and large) and my hobby project is a game so there was never need to open another window
Thanks, all the context in context is actually little weird but I think I'll dig in it later.
About the popup solution, first of all cool! second, the popup is google login and opened by service, if I'll call the service directly by the view it's not "kill" the module concept? I mean, suddenly I just skipping from the view to the service. little weird isn't?
I just upload my code to github if you may check it out and correct me if I'm doing things wrong, I'm not using DSL for now :) sorry if I'm bother you :O
About the popup solution, first of all cool! second, the popup is google login and opened by service, if I'll call the service directly by the view it's not "kill" the module concept? I mean, suddenly I just skipping from the view to the service. little weird isn't?
I just upload my code to github if you may check it out and correct me if I'm doing things wrong, I'm not using DSL for now :) sorry if I'm bother you :O
hey... so I went through the repo you sent and I can see couple of problems. Mainly it's about the way how things are coupled together... basically the View shouldn't know that there is such a thing as a service and it shouldn't even care about some module... view should only contain things like triggers... so ideally the
The creation of LoginModule should be done in the main class - basically you want to create the module in main and give it the view and the service. The module knows how to control everything and it knows that the view implements the interface so it can connect to the exposed trigger directly to the controllers
ILoginView interface should contain trigger called something like onLoginRequested which will be triggered when user clicks on the button (the setUsername method is fine, no coupling to outside world).The creation of LoginModule should be done in the main class - basically you want to create the module in main and give it the view and the service. The module knows how to control everything and it knows that the view implements the interface so it can connect to the exposed trigger directly to the controllers
login method (in my opinion it can even connect the trigger directly to the service call but that's just matter of taste)
regarding the injection of model into view... my idea would be to just inject the method, not the whole model... so something like:
//where you're creating the mappings
injector.mapClassNameToValue("Void->Void", model.someFunction);
//and in the view
@Inject
public var someFunction:Void->Void;
... and as always, sorry for the late response and thank you for your patience ;)
Thanks a lot! I updated my repository with some fixes...
I encounter with irritating problem, in My model I trying to fire a trigger, but it's not file anything for some reason the trigger is empty(in console I see:
I encounter with irritating problem, in My model I trying to fire a trigger, but it's not file anything for some reason the trigger is empty(in console I see:
Object { _inputs: Array[0] }) it worked before my changes :( please take a look.
I'm continue trying some things with hexMachina and I inject controller to my view:
@Inject
public var controller:IGeneratorController;When I tried in module insert the view into injector like following, it didn't worked:
this.getInjector().mapToValue(ITransferView, transferView);But this working:
this.getInjector().injectInto(transferView);what injectInto do?
And also, I should to "attach" to view into the module (i.e "mapToValue") and not the module to view (i.e "injectInto"), I'm afraid that I not exactly understand the "Injector" thing...
Hm... I think I understand the injector thing: each object that implements
IInjectorContainer get an injector object, but it's empty, so in the module I should "share" the module's injector with view's injector by this.getInjector().injectInto(transferView);, but if I want add something to module injector I just need to "map it in" by this.getInjector().map methods or by this._map etc...
the way map method works is following:
// code:
injector.map(ClassX).toValue(x);
// english:
// every time when something requires ClassX provide it this specific value x ... aka singleton pattern
//-----
// code:
injector.map(ClassX).toType(ClassX);
// english:
// every time when something requires ClassX create a new instance of ClassX and provide that instance ... aka factory pattern
so that's what map does
injector.injectInto(instance) does following... it takes the instance you're passing in and goes through all the pre-reflected data (generated by the IInjectorContainer described above) and does injector.getInstance(_whatever type is the public variable type_) which returns instances based on the mapping (or rules in other words) described above
so yes... you understand it pretty much correctly.... btw: in the module
this._map is just a shortcut for this._injector.map
btw: a small teaser - myself and @aliokan will host a hands-on hexMachina injector and DSL workshop at Haxe Summit in September and all the things I described above will be there with Rick and Morty themed coding examples and exercises ;)
Hey guys!
After some other tasks that I had to do I come back to hexMachina.
I solved this problem now but to understand, if I'm not mapping as singleton (i.e:
After some other tasks that I had to do I come back to hexMachina.
I solved this problem now but to understand, if I'm not mapping as singleton (i.e:
this._map(ILoginModel, LoginModel, '', true);) so when I'm doing _get (i.e: this._get(ILoginModel)) I'm getting a new instance of LoginModel? (lol when I'm writing this it's makes more sense)
btw: here's the mentioned workshop - https://github.com/DoclerLabs/hexWorkshop slides for each section are written in markdown in each corresponding folder (for example: hexInject/slides_content.md)
Which kind of problem?
@st3veV I wanted to put a link to the great rick and morty workshop, but didn't find it on Summit youtube channel: https://www.youtube.com/channel/UCGTson1aVohkJnbrqpNBXqg/videos?sort=dd&view=0&shelf_id=0
This is really excuting you guys remove a lit of reflections and such as we talked about a "light year" ago :)
Have this main class:
class Main extends App {
static function main() {
new Main();
}
override function init() {
super.init();
var injector = new Injector();
var vo = new VO();
vo.val = 'bar';
injector.map(VO).toValue(vo);
var container = new Container();
injector.injectInto(container);
}
}
This is VO:
class VO {
public var val = 'foo';
public function new() {
}
}
And Container:
class Container implements hex.di.IInjectorContainer {
@inject
var _vo:VO;
public function new() {
}
@PostConstruct
public function enter() {
trace("vo.val:" + _vo.val);
}
}
When it gets to Container.enter it fails with
Uncaught TypeError: Cannot read property 'val' of undefined
