Titanium JIRA Archive
Alloy (ALOY)

[ALOY-413] Allow views to explicitly define the associated controller

GitHub Issuen/a
TypeNew Feature
PriorityHigh
StatusOpen
ResolutionUnresolved
Affected Version/sn/a
Fix Version/sAlloy 2.0.0
ComponentsRuntime, XML
Labelsn/a
ReporterTony Lukasavage
AssigneeUnknown
Created2012-12-04T13:59:19.000+0000
Updated2018-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.

Comments

  1. Kevin Whinnery 2012-12-04

    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.
  2. Tony Lukasavage 2012-12-04

    I was planning on making it space-separated. :)
  3. Kevin Whinnery 2012-12-04

    commas or I boycott the framework.
  4. Ronald Treur 2014-04-23

    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? ;-))

JSON Source