[ALOY-747] Alloy: Add attributes to override create, add and remove methods
GitHub Issue | n/a |
---|---|
Type | New Feature |
Priority | n/a |
Status | Closed |
Resolution | Won't Fix |
Resolution Date | 2013-07-17T20:57:33.000+0000 |
Affected Version/s | n/a |
Fix Version/s | 2013 Sprint 15 |
Components | XML |
Labels | alloy, compare, views |
Reporter | Fokke Zandbergen |
Assignee | Tony Lukasavage |
Created | 2013-07-15T06:13:40.000+0000 |
Updated | 2013-07-22T17:58:42.000+0000 |
Description
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:
<Alloy>
<MyView ns="my.factory" toCreate="get" toAdd="attach">
<Label>Some label</Label>
</MyView>
</Alloy>
properly translates into:
if (typeof MyFactory === 'undefined') var MyFactory = require('my.factory');
$.__views.__alloyId1 = MyFactory.get({ .. });
$.__views.__alloyId2 = Ti.UI.createLabel({ text: 'Some label, .. });
$.__views.__alloyId1.attach($.__views.__alloyId2);
Here is the PR: https://github.com/appcelerator/alloy/pull/179
Why would I do this as opposed to just creating a separate controller/view and referencing it with
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.But would the ability to nest elements in
I just discovered another, more crucial one :) By default, in
compilerUtils.js
on line 253, Alloy uses.addEventListener
forTi.
namespaces and.on
for all others when using theonEvent
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
;)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.
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.
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).
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.
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.
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.
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.