In the angular dart documentation it says best practice is to declare your controllers using controller annotations. But I get an error when trying to do that stating that annotations must be a constant variable. Digging into the source I can see that there is no controller annotation in angular dart 1.0
From package:angular/core/annotation.dart
export "package:angular/core/annotation_src.dart" show
AttachAware,
DetachAware,
ShadowRootAware,
Formatter,
DirectiveBinder,
DirectiveBinderFn,
Directive,
Component,
Decorator,
Visibility,
DirectiveAnnotation,
NgAttr,
NgCallback,
NgOneWay,
NgOneWayOneTime,
NgTwoWay;
Has the controller annotation been depreciated? If so, what is the best practice for instantiating a controller?
Controller were removed in Angular.dart 1.0.
There is a rootContext which is a controller initialized at application startup, otherwise use a component instead of a controller.
See for an example
https://github.com/angular/angular.dart/blob/master/example/web/todo.dart#L116
https://github.com/angular/angular.dart/commit/e6a0f7747e7f890f35cb1201ef65eaf080fcfc5c
Related
I have followed the tutorials and now I am trying to extend that learning into a real app. In my app I use a JSON model. Unlike the tutorials, mine is a real-world app and I have to get user credentials to act as a filter when I load the data model. In the tutorials the model is loaded in component.js. In my app I have to prompt the user for id and password so I have a login fragment that appears modally over the first view in the app. This happens to be a master view, and critically it runs after component.js. After validating the user I collect JSON data from the server via Ajax and place it into the default model via this.setData(my_json).
When testing the routing from master to detail view I produced a stubborn bug in that this.getModel() called in the detail view produced an empty model. Huh - I just set the model in the master view and can see the data in the table control - what gives?
I considered a routing issue but confirmed that was not the problem - I can console log the parameters that pass through the router and anyway the detail view appears so routing is ok.
Recap: I use this.setModel() in the master page then this.getModel() in the detail page but the latter is an empty model.
Question: I want the model to be available across the app. The tutorials focus on setting model in component.js but I cannot. What is the correct syntax for setting the global model from the master view for example, or any other place that is not the component.js.
I think I need to use the following in the master (last line is significant):
var oModel = new JSONModel(); // declare a JSON model
oModel.setData(<json string>); // load a JSON string fetched from serve etc.
sap.ui.getCore().setModel(oModel); // important - set as the core model
I think the source of my confusion is that in the tutorials it seems that models are set in the component via
this.setModel(oModel); // a line in component.js
I therefore assume that this in component.js context is app-global whilst this in a view relates to the view along, which makes sense. Am I right?
In the tutorials this.setModel(...) inside the Component.js will set the model on the Component directly. Therefore, the model is visible in all views inside that Component.
When you see this.getView().setModel(...) inside a controller you know that the model is only set on that one view (and therefore it's also visible for it's children).
However, if you see something like this.setModel(...) inside a controller you should check what happens inside this.setModel(...). It is possible that the model is set on the view, or on the Component, or even somewhere else! Some of the tutorials make use of the so called "BaseController" concept. This is basically a parent controller of other controllers and therefore this approach allows to code some handy APIs that you can easily reuse in the child controllers that extend from this BaseController. For example, have a look at the BaseController of the Worklist App. There you can see that the setModel(...) API is setting the model on the view. That means whenever you call this.setModel(...) in your controllers which extend from that BaseController your model is set on the view!
Furthermore, because in a Master-Detail app there is no hierarchy between Master and Details page (parent/child relation) your models on the Master view are not visible on the Detail view.
In your case it seems to be best setting the model on the Component directly. You can do this by calling
this.getOwnerComponent().setModel(...);
inside any of your controllers. Or just do it directly on the Component.js like in the Wordlist tutorial. You can propagate the data to that model later, i.e. at anytime later from within your controllers.
With no view specificied in FuelPHP 1.6, the default was to load the view located in /views/controller/action but I'm trying FuelPHP 1.7 now and when I don't explicitly forge a view I just get a white output screen. (I checked that is isn't breaking by echoing)
Is this expected behavior? Do views now need to be explicitly called every time?
FuelPHP has never had any code in the default controller classes that loads views automatically based on the controller and action. It sounds like this is custom behaviour that has been added to your application by either yourself or another developer on your project.
You should check what is in the before and after methods of your parent controller as it seems that a minor change in 1.7 has broken your application's logic.
If you get a white output screen, it's actually a normal behavior. You have to forge a view on the methods of your controller.
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
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).
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.