I'm new to component development but I've read a lot online over the past month and I have the excellent Dexter/Landry book, "Joomla! Programming".
I'm really struggling with getting an understanding of how
data flows through the component and
control flows especially between views. I understand the 'high level' MVC concepts but I can't find a resource that brings this down to the level of actual methods/functions and data. Maybe someone who's had the same struggle could point me in the right direction ?
My most immediate problem is controlling flow between (form) views, eg, I want to 'Save' on view1 and be brought to view2. On entering data in view2 I want to 'Save' and be brought to view3 etc.
All help very much appreciated!
Related
I'm curious to know how to create the sidebar used in twitter and many other Apps
What i'm asking for is not about graphics, but i'd like to know which is the better way to create a structure to permit switching between different sections.
I don't like asking for help without start by an opinion, thus, this is mine:
Generic view structure would be created with a NSSplitView
I Need a generic Model class managing sections and taking a pointer to the current one.
Here i'd add informations about image used for any section etc... (something like a custom UITabBarController for iOS.
The Left view of the split View would be connected to the generic Model and would be able to present its section and get the current one. Pushing a button will ask the generic Model to change the current section and load content in the Right view (some doubts about this use a Model that way :P probably not the better one)
The Right view loads other view controller as requested by left View (i have may doubts about how do that!)
I'm on the right way ? how would you build a structure like that of Twitter ?
(Off topic: I'd really appreciate correction of my terrible English to keep this question suitable for all users)
Here's what you need https://github.com/erndev/EDSidebar
That's pretty much how I would do it although what you call a "generic model" object, I would call a controller (because it fits in the controller part of MVC).
The right view would be a Tab View with the style set to "tabless" so you don't get the selection buttons at the top and the individual views within the tab view would be selected by the controller using -selectTabViewItemWithIdentifier:
That's how I would do it anyway.
my pivotitems each require different odata calls in order to populate data in them.
must i make all those calls when the pivot is intialized or is there a way to fire each call when the user flicks to that pivotitem?
Any example of this will be appreciated.
thanks
You may choose both approaches in different situations.
From user experience view, preload all data is always better. In this situation, when user scrolls to the next page data is already there. Note, that first page you must load as fast as you can (use some delay approaches for other pages, for example).
Write out all pros and cons that you achieve, and you make a right choice ;)
I have a pretty good idea how each of these patterns work and know about some of the minor differences between them, but are they really all that different from each other?
It seems to me that the Presenter, Presentation Model, ViewModel and Controller are essentially the same concept.
Why couldn't I classify all of these concepts as controllers? I feel like it might simplify the entire idea a great deal.
Can anyone give a clear description of their differences?
I want to clarify that I do understand how the patterns work, and have implemented most of them in one technology or another. What I am really looking for is someone's experience with one of these patterns, and why they would not consider their ViewModel a Controller for instance.
I'll give some reputation points for this, but I'm looking for a really good answer.
Besides the already mentioned great reads (Fowler & Miller) and to reply to your point on differences among controller/ presenter/ ... from the developer's point of view:
Controller in MVC:
Controller is the actual component that gets called as a result of user interaction. Developer does not have to write code to delegate calls to the Controller.
Controller gets current values somehow from the View/ context/ bag/ whatever, but you would not really say that it interacts with the View.
Controller decides in the end which View to show back to the user. In that, Controller shows an explicit notion of application navigation workflow too.
Presenter in MVP:
Presenter has methods called by the View, which is the actual component receiving control upon user interaction. Developer has to write some code in the View in order to call the Presenter.
Presenter gets current values somehow from the View or receives them from the View upon call. Presenter calls methods on the View in order to set its state (populate it says Josh Smith). A View method called by the Presenter might have several small settings performed in its body.
Presenter does not explicitly show a notion of application workflow. It is usually thought of as returning control to the calling View.
PresentationModel in PM:
PresentationModel has methods called by the View, which is the actual component receiving control upon user interaction. Developer has to write some code in the View in order to call the PresentationModel.
PresentationModel has a much more chatty communication with View compared to a Presenter. It also contains more logic in order to figure out the value of all the settings to apply in the View, and to actually set those in the View. Those View methods in turns have almost no logic.
PresentationModel does not explicitly show a notion of application workflow. It is usually thought of as returning control to the calling View.
ViewModel in MVVM:
ViewModel has methods called (& properties set) by the View, which is the actual component receiving control upon user interaction. Developer has to write some (declarative) code in the View in order to call the ViewModel.
ViewModel has not an explicitly chatty communication with View compared to PresentationModel (i.e. it does not call View a lot, the framework does it). But it has a lot of properties that map 1 to 1 with View settings. It still contains the same logic to figure out the value of all those settings.
ViewModel does not explicitly show a notion of application workflow. It is usually thought of as returning control to the calling View.
Copying somehow what Josh Smith says (http://msdn.microsoft.com/en-us/magazine/dd419663.aspx): MVVM pattern is a special case of PM that takes advantage of a framework (like WPF/SL) in order to write less code.
Martin Fowler has a page on UI design patterns, in which he defines and then talks about MVC, MVP and other patterns.
http://martinfowler.com/eaaDev/uiArchs.html
A Controller is active in controlling the UI. For example it would handle any events triggered by the UI and deal with them appropriately.
A Presenter on the other hand is more passive, and simply displays data through the UI, which handles it's own events etc, or delegates them through the presenter to a service or command.
A ViewModel is a specific example of a Presenter, designed for use with WPF/Silverlight binding.
A Presentation Model is a model that can be presented directly by the view, so for example if your models implement INotifyPropertyChanged for data binding, they would be Presentation Models.
The difference between them is essentially in how much code is in the view. The choice between them is in fact a choice of technology for application such as WFP, WinForms, ASP MVC(2). The basic idea of separating logic from presentation is the same.
Here is very good article about all three.
EDIT:
One more article - comparison.
In my opinion, there are no real conceptual differences between MVP, MVVC, MVC and Presentation Model. There are some detailed differences, but in the end, it can all continue to be thought of as a Model View Controller setup. The extra naming just serves to create confusion, and I think it would be better to adopt terminology that allows for a certain amount of latitude in describing a controller.
At least in .Net, MVP is used as a design pattern. This usually is used with Windows Forms applications, or classic ASP.Net . With MVC, and MVVC, these are usually used with ASP MVC, which uses a fairly different architecture than normal ASP.Net.
One important distinction between MVP and MVVM is that VM can be used with many views, MVP is usually 1-1 between Presenter and View with a contract interface that enforces its methods.
Android has done much to incorporate MVVM with the ViewModel component that is built on top of a retained Fragment. It is the pattern of choice for Architecture and well suited for any app.
I have a question regarding MVC design, based on the Stanford iPhone lectures.
I have 3 classes;
Polygon - this holds information like number of sides and so on. This is my Model class
Controller - this responds to things like button presses in the view and then calles methods in the model to increase and decrease the number of sides etc. This is my controller (surprise!)
View - For this question the view will be a Class representing a single view, which draws the polygon to screen.
My question is what is the best way for the View class to obtain information pertaining to the Polygon model class? Although this is trivial for this example I'm hoping that the answer wil help me when building more complicated applications. Options I have;
1) Pass the instance of the Polygon class to the View so the view has a pointer to it. Then I can just call refresh at any time and the view will know what to do. This is what i would usually do but seens to break the MVC approach as the View and Model seem to be bypassing the controller, which makes me think this may not be the best way.
2) Have a redraw(...) method in the view, which takes as its args whatever new information received. This seems clean but would not scale well i would think.
Any advice would be great. As I say usually I would do option one, but would love someone to tell me something to improve the way i think about this....
Thanks!
The essential thing here is coupling. If it’s too tight, the design will suffer, you will repeat yourself and the code will be hard to maintain. If it’s too loose, it makes simple things too hard to manage. If you want to draw a simple polygon based on some model, you should have the model at hand, for it would be crazy to pull all the vertices through a controller. After all, the view is specifically written to display a polygon, so that it is perfectly natural to have a pointer to its representation.
What view does not care about is the context, the “life story” of the displayed object. It might come from the network, it may change soon, it may become twice as big when you click on it. The view does not care. If you click on it, the view can report the event back to controller and does not care about it any more. If the object changes, the controller will tell the view to update.
I don’t think there is a hard rule for designing such relationships, but the point is simple: keep loose coupling without sweating the details too much. It often helps me to think about testing and changes. Can I isolate the model for testing? Can I use a completely different view without changing the other parts? Could I write a different user interface based on the same model? How about a different “skin”? How much would I have to rewrite?
your view should be doing nothing but showing the view. so if you need to show updated information in the view, you either do it from cache (which isn't really applicable here, but I'm throwing that out because its something I've been doing lots lately with web stuff), or you re-engage the controller and get the controller to call the view again with updated data about the model.
so technically, your second option is the more correct one. the view should redraw itself by calling the controller and asking it for updated information.
Model is data. Controller is logic. View is display.
As such, the Model be like a data clerk. The controller should be like a administrator or team leader in an office. And the view should be like a news reporter reading a teleprompt reader.
The controller can boss everyone around, and controls the data entered and the text on the teleprompter - and outsources the actual work to the model (for data) and view (for display).
As such, to answer your question. The view should just do echo $this->view->myPentagon->someAttribute. The controller fetches the myPentagon object from the model, and assigns it to the view object. The model handles the data structure and database api. The view handles the display. The controller tells the view when to display.
I'm developing an app which has a large amount of related form data to be handled. I'm using a MVC structure and all of the related data is represented in my models, along with the handling of data validation from form submissions. I'm looking for some advice on a good way to approach laying out my controllers - basically I will have a huge form which will be broken down into manageable categories (similar to a credit card app) where the user progresses through each stage/category filling out the answers. All of these form categories are related to the main relation/object, but not to each other.
Does it make more sense to have each subform/category as a method in the main controller class (which will make that one controller fairly massive), or would it be better to break each category into a subclass of the main controller? It may be just for neatness that the second approach is better, but I'm struggling to see much of a difference between either creating a new method for each category (which communicates with the model and outputs errors/success) or creating a new controller to handle the same functionality.
Thanks in advance for any guidance!
My preference would be to create triplet Form-Controller-Model for every form displayed to the user. Whenever user clicks on 'Next' button on a form its controller should talk to the back end manager which takes care of dispatching submit request to the next form in chain. Vice verse if 'Back' button is clicked. Last form has a 'Finish' button which will go to the manager and pass the last bits of information.
This will avoid inheritance, make your code more robust and testing of forms possible in isolation.
My preference would be to keep it all in one controller. It keeps all the relevant processes for filling out the application/form in one place, although I'm not sure how "massive" you're talking about. If you do decide to split it out, I would not subclass off of the main controller, but just make a handful of independent controllers, perhaps related by name for ease of use down the road.