I am confused about components data.
Parent to Child use props.
Child to Parent use emit.
I am thinking about difference.
What I have learned, emit need event to transfer data.
So, the example, I learned it always combine event like 'click'
This is point what I confused.
Why child to parent need emit event to send data.
I am think about are there certain way send data from child to parent no use event?
Related
I'm a fairly experienced programmer, but I've always struggled with this particular issue..
You have your main class that maybe displays pop-ups over everything else, transitions between screens and so forth, and then you have the screen objects themselves, and the pop-up objects. when you click "close" on a pop-up, or click "go to a new screen" on a screen, or whatever it may be, these objects then need to communicate with the main class and tell it to do stuff. And often you need to pass data to the main class aswell. In your experience does it work out better to have the children dispatch events with data, that the main class picks up, or somehow pass the main class down to all the children through constructors, and have a bunch of public methods in the main class that the children can call?
or are both equally valid?
edit: And also, what made me post this: In my game, the user goes through a bunch of different menu screens, and in each screen, he adds something to a game-config object that at the end will be used to generate the gameScreen. I dont want to keep saying dispatchEvent("addValueToGameConfig", value) or something, i just want to say bigController.gameConfig.value = "whatever";
If the hierarchy of children is deep, I would go for events or observer. It leads to a lower coupling between classes. Any substantial refactoring of your main class can have a huge avalanche effect on the dependent children. They become too knowledgeable (higher change of breaking Law of Demeter) about their parent and take on effectively an additional responsibility (arguably breaking SRP) besides managing their own state, of informing it constantly about their own state in a custom manner compatible with their parent. Firing a specialized meaningful notification about their state change into "space", not just about an arbitrary property change, releases them from worrying about the parent's state. It is a parent's duty now to be informed about changes of the state of its children. Furthermore, having a set of meaningful events can lead to narrower public interface of children. It may as well help readability, not having to constantly go up and down through the hierarchy.
All:
I got one question about the the wxDialog Destry():
Suppose I make a dialog which inheritate from wxDialog like:
wxMyDialog dlg = new wxMyDialog(.....the pararmeter.....)
and inside wxMyDialog, there are some wxwidgets pointers like wxbutton*, wxBoxSizer* ....
I read some tutorials, most of them do not mention what happen to those inside pointers, so I wonder, when I call dlg->Destroy(), can all those pointers be automatically free? Can someone tell me what happen behind Destroy()?
or
if not, how can I free them mannually?
Best,
When you create the widget pointer inside your dialog, you pass a pointer to parent dialog. The parent keeps these pointers, and when the parent dialog is destoyed, delete is called on those pointers. So, you see, every window cleans up its own children.
Bottom line: children are 'owned' by their parents and you never need to worry about tidying up after them - the parents do it.
A couple of special cases:
If you pass NULL as the parent window to the widget creator, this means that the widget belongs to the desktop window, not the application. You should NOT do this for anything other that a top level window!
You do not pass the parent window pointer to the constructor of a sizer. Instead you pass the sizer pointer to the parent window's SetSizer method - which has the same effect, the parent windows owns the sizer and deletes it when the window is destroyed.
Is it possible to receive notifications if, for a specific parent AXUIelement, any of it's children change (an attributes), or a child is added/removed?
For added/removed You can get notified if an element is created with NSAccessibilityCreatedNotification (and then check if it has the appropriate parent) and destroyed with NSAccessibilityUIElementDestroyedNotification. I don't see a accessibility notification for arbitrary attribute changes.
I am trying to figure out the purpose of what the .parent property achieves in this method and the "get[ClassNameHere]" methods in general that feature this property being called.
-(HudLayer*) getHud
{
return (HudLayer*)[self.parent.parent.parent getChildByTag:kTagHudLayer];
}
It's not possible to know the details from just this method shown here. But the .parent does return the Cocos parent, sprite or layer, to which the current cocos object belongs as a child. Essentially this code suggests you have a sprite or layer with a child that has more children and more children of those children, and this is a way to find out who the big parent up the stream is, and then get a new child from that parent.
Personally it seems pretty sloppy to me. I'd never code that way myself. Hard to read (as you can see) and having so many parent properties strung together like this is opening a lot of room for bugs. It would be wiser if the top parent did what it needs to do rather than a distant grandchild going up the chain; it breaks the MVC model a bit to do it as shown here.
Probably class HudLayer has a parent property that points to another object of the same kind, thus having a parent property pointing to another HudLayer and so on, climbing up for three levels. Then it just sends a getChildByTag message to it.
Why do I need to add relationships for child and parent?
Child child = Session.Get(1);
Parent parent = Session.Load(1);
parent.Children.Add(child);
child.Parent = parent;
It works perfectly without parent.Children.Add(child) if use inverse=true and I don't need Children collection in current session (session per web request). Do you always add relationship for child and parent?
Setting child.Parent = parent is enough to persist the relationship.
However, if you don't add the child to the collection, you won't be able to take advantage of cascading, so you'll have to persist the child explicitly.
Also, if you don't set one of the sides, you'll have an inconsistent memory model (because the child won't be added to the collection unless you reload it).
I hope I understood you correctly.
class Parent { List Children {get;set;}
class Child { Parent Parent {get;set;}
ANS1. In this scenario Inverse tells the nhibernate framework to leave the control mechanism of [Parent-Child] relationship to the Child (it is mostly about which object is responsible for Deleting/Updating the Child). With Inverse attribute on Children property Child is responsible for itself, otherwise Parent is responsible for deleting a Child.
ANS2. You do not need both properties (Children, Parent) in most cases (you need them if you specify inverse=true on Children). It only depends on the functionality you want to get.
Does this briefly answer your question?