Titanium JIRA Archive
Alloy (ALOY)

[ALOY-747] Alloy: Add attributes to override create, add and remove methods

GitHub Issuen/a
TypeNew Feature
ResolutionWon't Fix
Resolution Date2013-07-17T20:57:33.000+0000
Affected Version/sn/a
Fix Version/s2013 Sprint 15
Labelsalloy, compare, views
ReporterFokke Zandbergen
AssigneeTony Lukasavage


This issue builds forth on TC-2609, asking for dynamic namespace loading for Alloy view components. If using existing object factories, being either native or CommonJS modules, these might not always follow the convention of createTagName, add and remove for creating the view component, adding a child to it or removing it. Using optional toCreate, toAdd, toRemove attributes, one should be able to override these defaults, so that:
  <MyView ns="my.factory" toCreate="get" toAdd="attach">
    <Label>Some label</Label>
properly translates into:
if (typeof MyFactory === 'undefined') var MyFactory = require('my.factory');
$.__views.__alloyId1 = MyFactory.get({ .. });
$.__views.__alloyId2 = Ti.UI.createLabel({ text: 'Some label, .. });


  1. Fokke Zandbergen 2013-07-15

    Here is the PR: https://github.com/appcelerator/alloy/pull/179
  2. Tony Lukasavage 2013-07-15

    Why would I do this as opposed to just creating a separate controller/view and referencing it with ? This seems like a lot of cruft in the XML attributes to do something that is essentially already solved with self-contained controllers. I would prefer to focus on resolving the issue that XML elements can't be nested inside or attributes. Would that work just as well for you?
  3. Fokke Zandbergen 2013-07-15

    Well, I can think of two reasons: * Using ns like discussed in ALOY-743 the view could come from a native module as well. * This could be a good way to include legacy code in a app rewritten (partially) in Alloy.
  4. Tony Lukasavage 2013-07-15

    But would the ability to nest elements in make this easier? It wouldn't cover handling legacy code, but that's not a primary concern of mine. My main issue is that I feel that Alloy has almost too many special XML attributes as it stands, I'm very hesitant to add anymore because it will be (near) impossible to remove them if and when we do find a cleaner way to implement this. It just feels a little to shoe-horned in when can do the bulk of this already.
  5. Fokke Zandbergen 2013-07-15

    I just discovered another, more crucial one :) By default, in compilerUtils.js on line 253, Alloy uses .addEventListener for Ti. namespaces and .on for all others when using the onEvent attribute in views. If I have my own factory wrapping Titanium proxy objects, this won't work. So I guess I would like to add a 4th: toBind ;)
  6. Tony Lukasavage 2013-07-15

    As I think you are realizing, it's feeling far to "bolted on" to go through at this point. There's just too many little things to consider and I don't want to add an XML attribute every time we find another one.
  7. Fokke Zandbergen 2013-07-16

    What about instead introducing one new element to register new namespace objects? That would be similar to registering namespaces in HTML and more clear because you're aware of what you're doing.
         <Namespace ns="my.namespace" require="myNamespace" create="get" add="attach" remove="dettach" />
         <SomeView ns="my.namespace" />
    This element should be used to inform Alloy on a namespace's behavior (create/add/remove) as well as optionally specifying a CommonJS/native module to require (if not already in global scope).
  8. Tony Lukasavage 2013-07-17

  9. Tony Lukasavage 2013-07-17

    In short, I like the ability to allow arbitrary UI components to be inserted via XML, but I don't want this crazy level of flexibility managed in XML. New UI components should abide by the standard interface for creating components and adding/removing them from the view hierarchy.
       <SomeComponent ns="my.stuff"/>
    is expected to implement my.stuff.createSomeComponent(), my.stuff.SomeComponent.add(), my.stuff.SomeComponent.remove(), and any other Titanium-like function that it may make use of. We should more clearly define this interface, but allowing an arbitrary interface is deviating too far from creating a coding standard, which is what Alloy is aiming to do.
  10. Tony Lukasavage 2013-07-17

    Closing this as based on our conversation I don't think this method or the associated PR best suits Alloy goal of establishing a clear coding standard. I'll be happy to continue the conversation, but I think cleaner long-term solutions have been put forth.
  11. Fokke Zandbergen 2013-07-18

    I can live with this decision ;) Writing a custom parser would be too complicated and time consuming for most I think, but I agree that asking of modules to follow the create, add, remove and even 'on' convention is not too much asked. Then the only issue left is a more clean loading of the module, but we'll discuss that further in ALOY-743.

JSON Source