[ALOY-413] Allow views to explicitly define the associated controller
GitHub Issue | n/a |
---|---|
Type | New Feature |
Priority | High |
Status | Open |
Resolution | Unresolved |
Affected Version/s | n/a |
Fix Version/s | Alloy 2.0.0 |
Components | Runtime, XML |
Labels | n/a |
Reporter | Tony Lukasavage |
Assignee | Unknown |
Created | 2012-12-04T13:59:19.000+0000 |
Updated | 2018-03-07T22:25:33.000+0000 |
Description
Let's allow developers to explicitly define which controller they would like to associate with a given view. Currently, a controller is associated with a view simply by having the same name. But there are cases where you'll want multiple views to be able to use the same controller code. Loosely coupling views and controllers will allow for less LOC and more manageable code. For example, the [tableview_binding test app](https://github.com/appcelerator/alloy/tree/master/test/apps/models/tableview_binding) could make very good use of this ability.
Here's a simple proposed syntax for doing so:
<Alloy controller="path/to/someController">
<!-- the rest of your markup -->
</Alloy>
Alloy will handle the association under the hood, the developer will simply need to specify the name of the controller to use.
Suggestion: make the controller attribute accept a comma-separated list of controllers, which would be inlined in the generated "component" in the same way the single controller is today.
I was planning on making it space-separated. :)
commas or I boycott the framework.
This issue kinda turns the way classic MVC-frameworks operate on its head. In this classic approach a View should be useable by any Controller and it is up to the Controller to make that decision. Views are simply 'dumbed down' templates, waiting for a Controller to fill them with meaning. Now I know that Alloy already empowered the Views for a bit, but personally I would (for the sake of consistency with other MVC-frameworks) still suggest to stick to the that approach. So in fact I would suggest the complete opposite: Give Controllers the freedom to pick the View(s) they want. This still solves the case mentioned in this ticket's description, where you wanted a single Controller to be able to use multiple Views (see what I did there? ;-))