I've been trying out zf2 for a couple of weeks and generally enjoy working with it. I have trouble though deciding where to do specific tasks. Does a function belong in the model or in the controller etc.
At the moment I would like to understand the view helper and controller plugin concepts.
Could anyone give a few examples what kind of functionality belongs in a view helper?
I would like to know the same for the controller plugin, a few examples to make me understand why I would make a plugin instead of programming the functionality in the controller?
View helpers extend functionality on the view layer and are for reusability throughout your application.
Controller plugins extend functionality on the controller layer.
You generally use both to keep your controllers / views light and thin and reuse those in your application (keeping your code DRY).
Related
I am new to SAPUI5.
I have two components/folders with views & controllers named 'view' and 'tableview'. Is it possible get 'view' context in 'tableview' ?
If I understood correctly you are trying to access a parent controller from a child controller. Here are some proposals ordered from noob to expert ;)
The simplest approach would be to just use a global variable to provide reference to the controller you need - not recommended.
Give your parent view an id and call a method on it's controller like this:
sap.ui.getCore().byId("parentViewId").getController().method();
You can directly call a controllers method like this:
sap.ui.controller("namespace.Controllername").method();
I would highly recommend a more decoupled way of communication between controllers (or application components in general) using the sap.ui.core.EventBus. It implements a pattern known as Event or Message Bus and imho really rocks ;)
GL
Chris
Lets say that on all my views, or generally at any time in my app, I want to be able to show an error message popup, and it always looks the same. How do I do that?
First thought is having all my view models extend a base view model which facilitates these things, but after that, do I have this base view model actually create the UI widgets and display them?
thanks,
Mark
If you've got some common functionality that you want to provide across a range of views, then you can implement a base class that inherits from the PhoneApplicationPage, and then derive all your classes from that class instead. The XAML for your pages then looks like this:
<local:BasePage xmlns ...
xmlns:local="clr-namespace:MyNamespace"
x:Class="MyNamespace.MyPage">
However, you will not be able to define common UI components in the XAML for your base page. If you wanted to have common UI components you would have create them manually in the code-behind for the base page, perhaps in a handler for the Loaded event, but I think a better solution would be to provide your common UI in a UserControl, which you then add to each of your pages.
If you want to show a Toast or Message Box, then I would recommend the ToastRequestTrigger and MessageBoxRequestTrigger from the Silverlight Toolkit as described in the patterns & practices WP7 Developer Guide.
you could probably define an event on base view model, which is fired inside view model whenever an error occurs, then in view, you can subscribe to this event and display the popup. You can carry error context in EventArgs of the fired event.
Additionally you could unify the logic for displaying the popup but that's probably another story :)
This is testable and nicely decoupled from the view.
Hope this helps,
Robert
Could someone give few tips and/or examples how Controller Plugins and Action Helpers are different? Are there situations where particular task could be accomplished with one but not another? For me they both look more or less the same and I'm often having trouble having to decide when to use what... Are there any big differences?
Controller plugins can hook into any controller at any point in the routing process (preDispatch postDispatch, routeStartup, routeShutdown) which makes them apt at providing behind the scenes functionality like ACL enforcement.
Action Helpers are for for reusable but optional segments that your controller might need to access (redirector, flashMessenger).
So if you are creating a reusable snippet of code that always needs to execute itself then use a controller plugin, otherwise you probably want an action helper.
You can think of it this way:
Action helpers are used to add methods to controllers.
Controller plugins are used to add routing / dispatch logic to controllers.
So ask yourself, do I have a method that I would like to be able to call from all actions in my controller? Or do I need to add logic to the routing / dispatch process.
You might also have a look at the the Built in Action Helpers.
A picture to illustrate the difference between plugins and action helpers:
ZF Sequence Flow
Action helpers also have access to the actual controlller object that's being executed. Controller Plugins only have access to the FrontController, and therefore only the controller and action name.
Which you use depends on what context you need. If you need to access a view object attached to a controller, for example, you will want an Action Helper.
Also notice that, in the front controller life-cycle process, the plugins get the control(or invoked) first than the action helpers.
On startup, if the user hasn't done any setting of NSUserDefaults, I want my main view to do a flipside view that brings up the same stuff that shows up in the Settings app.
Is there an API for instantiating the same controller that Settings uses, or will I have to reimplement a table view and controller myself?
This website hosts the 'MySettings' API which is a nice toolkit that encapsulates various Settings features (switches, choices, etc) all in a declarative (plist-based) API.
You have to code the ui elements yourself if you wish to make the perferences available within your app. The utility template in xcode gives you a starting point by making a flipview available.
Check out Craig Hockenberry's Generic Table Views, which make it really easy to set up a Settings-like table view.
I've made an Area project for my ASP.NET MVC application called 'Admin'.
This will contain all the logic for the Administration section of the site, where the users can add/remove pages, etc.
There's a menu at the top, of things the user can manage. (E.g. 'Content', 'Users', etc)
For each of these, I'm making a controller ('ContentController', 'UsersController', etc)
I'm wondering how to setup the navigation, as there seem to be varying approaches.
One approach is to use MvcSiteMap, which involves creating a '.sitemap' file and decorating actions on my controllers with an 'MvcSiteMapNode' attribute.
The problem with the above is that it's complicated to implement (especially in an Area project, because of the way Areas work in ASP.NET MVC). It also seems like overkill.
I've come up with a different way, which is to decorate each controller with my own attribute. Then I have a helper method that renders my navigation by using reflection to loop through every controller, pick out the ones that have that attribute, and then add them to the navigation menu.
What are your thoughts on the above method? Can you think of an even simpler way of doing this?
So I've done it my way - an attribute on each controller, then a static method that reads all the attributes on application start (using reflection) and keeps them in memory.
So far this has worked perfectly, and I haven't needed any of the advanced features of MvcSiteMap.