ANSWERED BELOW
I have a problem with an Aurelia bindingcontext being replaced by the parent component.
I have a first component which has a sourceItem property which is bound in its view:
${sourceItem.Name}
This shows the correct value "Parent name"..
This component has a router-view in which another component is created. I can see this child component being created without problem. The problem is that this child component also has a sourceItem property which is bound in its view in the same way.
${sourceItem.Name}
This SHOULD show the value "Child name" but although I can see this second sourceItem being correctly created, the view displays the value of the parent binding context : "Parent name"
If I change the name of one of the sourceItem (to sourceItem1 for instance), everything works fine. Any idea if I did some mistake or if there is a bug hanging somewhere?
Thanks a lot!
EDIT FOR MORE INFO
I noticed that, when navigating to the child route, the problem occurs to me. But when I entered the full URL in the browser's bar and load the page, the binding works correctly. When I check the bindingContext & overrideContext (in the bind() method), the results are exactly the same. So it looks like it could be a timing issue...
I also posted this question on github and I got my answer.
In my case, I had some async code retrieving data from the server in the activate method of my child route's view model. The problem apparently came from the fact that the server didn't return before the binding engine was triggered so it took the information it could find (the parent's binding context).
I just had to return the promise from the activate method so aurelia would wait for the promise to return before launching the binding engine...
I guess this is working as intended as stated in the Docs:
The "scope" in aurelia is made up of two objects: the bindingContext (almost always a view-model instance) and the overrideContext which can be thought of as an "overlay" of the bindingContext. Properties on the overrideContext "override" corresponding properties on the bindingContext. It is actually rare for there to be a property on the overrideContext that is "hiding" a property on the bindingContext beneath. ...
See: http://aurelia.io/hub.html#/doc/article/aurelia/binding/latest/binding-how-it-works/3
Related
I have a Vaadin view that needs a parameter for its construction (e.g. number of weeks to show). However, commonly construction of a view is done in the constructor, while parameters are set in the setParameter method, which is called after the constructor.
Is there a way to build the view after the setParameter is called?
You can simply skip implementing the constructor and instead set up the whole view in setParameter or beforeEnter.
Depending on the case, you might have to be careful to avoid problems if the user can navigate directly to the same view but with another parameter value since in that case setParameter (or beforeEnter) would be called again for the same instance which means that you might end up setting up everything again and thus end up with duplicates in the view.
I am facing a problem with CDI on JBoss AS 7.1.1
I have two JSF-beas, where one has the CODI ViewAccessScope (Bean A) which shows all entities, and the second is plain RequestScoped (Bean B). Each Bean get a, so called, Presenter injected which takes care of all presentation logic. So far so good.
The Presenter from Bean B is responsible for creating a new entity (calling service...bla...blubb) and when everything is done Bean B is redirecting to another page but since Bean A now has to reload its content I introduced the JEE-6 Observer.
In detail: Both Beans (A & B) get a particular Presenter injected (which has a backrefrence to the jsf-bean via a interface). Bean-B-Presenter fires an event after the entity was successfully created, so that then Bean-A-Presenter (the Observer) can reload the data and notify Bean-A about the changes.
The Problem: I am getting as NullPointerException when the observing Presenter (A) reloads its data because the reference to Bean A is lost. The reason why this happens is because CDI is obviously creating a new Presenter-object (its annotated with #Named) instead of using the one that is coupled with Bean-A.
Workaround: when I use Bean-A as the Observer than everything works.
My code is pretty much the same as seen in the link I added. I don't understand why a new instance is created when firing the event.
UPDATE regarding LightGuards comment:
The presenter beans are just annotated with #Named (which should be Dependent-Scope by default).
I had a look at the Weld-Documentation and it looks like this scope is somehow isolating my beans from each other. I need the presenters to be a new instance, each time a view (jsf-bean) gets initialized (so no Singletons). On the other hand I want to be able to send events between them, meaning that only the already existing instances get notified (not that a new instance is created).
I just did a test with the presenters being RequestScoped. This doesnt work either because now on every HTTP-Request I get a new Presenter even though the view (jsf-bean) to which it belongs is ViewAccessScoped. SessionScope of course works...but this would result in the wrong design.
Sounds like you'll need to create your own scope for this usecase. None of the default scopes sound like they fit your need. Another option would be to look at MyFaces CODI and the conversation scope they're written.
Please ensure that your observers aren't private.
And you have to ensure that you redirect correctly.
I added a ParameterHandler to my application's main window so I can catch and process custom get parameters in my url. However, the presence of one parameter reloads the first page of my application, for some reason building this page triggers the handleParameters method again, this time with no parameters passed. If left unchecked (e.g. no ifs) the page's elements will just replicate themselves on top of themselves over and over again.
I suspect it has something to do with my main windows's addComponent method.
How can I stop it from doing that?
I completely forgot I still had this question open. I found that the problem was that the method got triggered for both get and post type parameters, and this is what caused the unexpected output.
I already implemented an HttpServletRequestListener because I used Vaadin's ThreadLocal pattern, so I just filtered all GET parameters out of the request object in one of the implemented methods and went from there.
debug your application and have a view at the call stack of the handleParameters method
Is it possible to put a placeholder for a method call in the property value of an object in the Object Inspector? I have a method that returns a string that I'd like to include as part of the connection-string properties of some TADOConnection objects. Changing the method's return value would alter what gets assigned to each of the connections as they're loaded from the DFM.
I'm using RAD Studio 2010.
No, you cant. You can only have properties and events, but:
You can create a set method in you Connection property. This set method you search all forms and datamodules in you application and it will try to find an TADOConnection. When it finds one, it willl change its connection property. But this will only works in design time in the current form you put your component into, but it would work fine on runtime. Thats is not a pleasent solution, maybe you should try what #TommyA said on comments.
When is the Session property in Controller Initialized?
From what I see it is not initialized when the constructor is called. So when it's initialized?
It looks to me from the source, that the controller context (which contains the HttpContext and thus the Session) is provided to the controller when the action is invoked by the ControllerActionInvoker. It's also available to filters via the filter's context object on the filter's main methods.
So this is old, but I thought I'd leave the answer here for someone in the future.
http://forums.asp.net/t/1500473.aspx
Some guy says the Session is created when you first use it. My own experience bears this out, with one caveat, if you have two action methods executing simultaneously then the first one to access the Session appears to end up with a different Session to the second. I put a lock around my code to try and solve this, but ended up solving it by initialising my Session earlier on in my process.