Form1 gets a request to perform some action. Form1 sends the request to my business logic class. If there's some error in the request, a notification is sent back to View1 and he presents an error message. If there is no error in the request, a new view must be created.
Who creates the new Form? Do I notify Form1 and have him create Form2? Does the business logic class call the Form2 constructor?
In the Model View Controller (MVC) design pattern the controller would create the new view. Using this paradigm the controller would receive the request from the view (i.e. Form1) and send it to the correct model (i.e. business logic class). Depending upon the results from the model the controller would either send a message back to Form1 or create a new view in Form2. This is a cleaner separation of concerns.
Related
I created a very simple new Cocoa application, with a new class and custom controller (or object in interface builder, the plain blue cube). I connected all outlets with interface builder and assigned the custom delegate to the class. The problem is, the code does not get executed (checked by setting breakpoints), the window presents itself, and there are no errors.
The code of the class is really irrelevant, I tried once before with a proper set up and it worked there, I couldn't spot the difference however.
The key here is a separate controller together with class instead of the standard App's Delegate, to integrate the project to a bigger one.
I have a NSDocument based application, which allows the user to send messages, after he has logged in.
These should be the user's steps:
The user starts the App and logs in (credentials are stored in the user model)
The user user sends the first message
The user hits CMD + N and sends another message (without having to log in again)
The message model is placed in the MyDocument.xib. However the user model should be place in a global place (I would say MainMenu.xib).
My question is now:
Does it make sense to put the model in the MainMenu.xib and how can I access it from MyDocument.m
Is there maybe a better way to do this properly without having to make a singleton class?
I would create an NSApplication delegate and then add you functionality in you delegate or an property of you delegate, you can then use [[NSApplicaton sharedApplicaton] delegate] to get you delegate. You application delegate is the place to associate model data that is common to you application.
I finally got it working with my NSApplication subclass (some say this is not the way to go). For this I had to change the principal class from NSApplication to my new custom NSApplication subclass.
I have more than one PasswordBox on my view and I want to pass all their SecureStrings to my view model when I click a button.
My guess is that I want to populate an instance of a custom class with all the SecureStrings and pass that object as a parameter to the RelayCommand bound to the button.
If I only knew how...
My current idea for a work around:
In the RelayCommands action for the button: send out a NotificationMessageAction with a callback taking a custom class as parameter.
Register for that message in the views code behind, and then populate an object with the SecureStrings, and then pass that object back to the view model with the help of the callback. Not very nice...
There must be a better way to do this in XAML, right?
Actually, I think what you want to do is implement event handlers, or an attached behavior on your PaswordBoxes that will push the SecureStrings to properties in the same viewmodel object that will be handling the RelayCommand's action. Then your RelayCommand won't need any parameters at all.
I'm confused somewhat by the MVC implementation as used in Objective C programming.
What is described as 'Controller' in Objective C tutorials and documentation, I understand as simply a view or mediator.
Which is correct?
A model is what holds your application's data — its model of the world.
A view is what interfaces with your user. It displays things and receives input back.
A controller handles the interactions between the other components. It tells a view how to find its content, it responds to changes in the view by updating the relevant parts of the model, and it responds to changes in the model by telling the view what needs updating.
View displays
Model holds data
Controller responds to user events and controls view and model.
Controller can't be a mediator, because view and model do not communicate with each other through it. But it controls them.
I cannot find documents about the way, in which Interface Builder determines the Sent Message outlets for the graphical connections between components triggering events and messages of other components.
I want to generate components encapsulating Finite State Automata. The input part is simple, just define IBAction messages and you can connect them in in Interface Builder. The tricky part is obviously the other end of such connections.
I want to provide for each event triggered by the FSM a distinct outlet, like the 'selector' outlet of a NSButton (listed under 'Sent Messages' on the 'Connections' tab of the inspector).
How do I specify such interfaces programmatically and can I specify more than one of these?
Or is this approach not suitable; would Notifications be a better way? (I am used graphical connections from Visual Age and Parts, so I would prefer them, but in Interface Builder, the support for such connections seems somehow limited).
Thanks in advance
The first part of my question has been ansered in the question 'Send An Action Cocoa - IBAction'. I am still looking for a possibility to define more than one 'Sent Message'.
When you implement your method using IBActions, the object that generated the message (the sender) is passed to the message. So if I have a button on my interface that says "Logout" and an action on some controller object named logout: and I have wired these up, the method receives the instance of the button that triggered it. For example:
- (void)logout:(id)sender
{
// sender is the instance of whichever wired button triggered
// this action. We just NSLog() it for now.
NSLog(#"-[%# logout:%#]", self, sender);
}
Other objects may call this action as well, and may pass themselves as the sender or may pass nil. The details of this would be left up to you as the designer.