Titanium JIRA Archive
Alloy (ALOY)

[ALOY-1018] Add defaultNamespace or module attribute to Alloy Tag

GitHub Issuen/a
TypeImprovement
PriorityLow
StatusResolved
ResolutionFixed
Resolution Date2014-10-30T05:44:53.000+0000
Affected Version/sn/a
Fix Version/sAlloy 1.7.0
ComponentsXML
Labelsn/a
ReporterJason Kneen
AssigneeTim Poulsen
Created2014-05-16T17:48:30.000+0000
Updated2015-11-03T21:41:11.000+0000

Description

Alloy currently has a feature of specifying a module attribute against tags, allowing a custom JS module to be used to create the elements, enabling developers to return modified or different elements. e.g:

Comments

  1. Fokke Zandbergen 2014-05-16

    1) You mean <Alloy module="ui" > without .js 2) This would require the compiler to require the module and check if create[Tag] exists. 3) module rocks: http://fokkezb.nl/2013/10/21/cross-platform-ui/
  2. Jason Kneen 2014-05-16

    1. Yes of course 2. Yep 3. Good plug.
  3. Tim Poulsen 2014-07-29

    So, I can implement this. However, since I don't know which of your tags would implement some custom functionality, I have to basically copy the module attribute to every tag. This, naturally breaks the runtime code generated for every tag that your custom function doesn't implement a specific create function for. To fix that, I have to implement some pretty inefficient code with lots of duplication. For example, this: 
       <Alloy module="testmod">
   	<Window>
   		<CustomButton top="100" title="Click Me"/>
   	</Window>
   </Alloy>
    generates this: 
       $.__views.index = require("testmod").createWindow ? require("testmod").createWindow({
       backgroundColor: "#fff",
       fullscreen: false,
       exitOnClose: true,
       id: "index"
   }) : Ti.UI.createWindow({
       backgroundColor: "#fff",
       fullscreen: false,
       exitOnClose: true,
       id: "index"
   });
    I'm sure I could optimize this more than I have here. Still, the change is going to make for rather different code generated if you do or don't use the default module attribute. I hesitate to implement such a minor productivity enhancement that comes with the potential for such results. Thoughts? Suggestions?
  4. Fokke Zandbergen 2014-07-30

    Or: 
       $.__views.index = (require("testmod").createWindow || Ti.UI.createWindow)({
       backgroundColor: "#fff",
       fullscreen: false,
       exitOnClose: true,
       id: "index"
   });
  5. Jason Kneen 2014-07-30

    like it
  6. Tim Poulsen 2014-07-30

    Right, like I said, I can do some optimization. But is the slowdown of a runtime check for every API call in a controller worth it for the few minutes of developer time saved by not having to specify module="foo" for those couple of components for which you'll be using custom modules for?
  7. Jason Kneen 2014-07-30

    I think treat this like the Dynamic TSS in Alloy - If not used sparingly it can be an overhead. If a developer wants to go this route then it's their choice? For my TabGroup concept, I have to add the attribute to the TabGroup, Tab and Window tags. Wouldn't this have the same overhead as adding it once to the Alloy Tag wrapping the TabGroup?
  8. Jason Kneen 2014-07-30

    I'd be interested in seeing it added to run some simple speed tests - see how much it does affect performance.
  9. Tim Poulsen 2014-07-30

    Can you grab from here and do some tests? https://github.com/skypanther/alloy/tree/ALOY-1018 (generated code now matches Fokke's comment)
  10. Fokke Zandbergen 2014-08-01

    I'm in France on a beach so if you don't mind [~jasonkneen], please test twice - one for me ;)
  11. Tim Poulsen 2014-10-27

    PR https://github.com/appcelerator/alloy/pull/614 Functional test: Run the included ALOY\-1018 test app. You should get an app with a blue-bordered button and a pink-background label which were created with custom tags defined in the testmod module.
  12. Feon Sua Xin Miao 2014-10-30

    Additional test note: 1. {color:blue} Blue {color} bordered custom button on iOS 2. {color:green} Green {color} bordered custom button on Android
  13. Feon Sua Xin Miao 2014-10-30

    PR merged.
  14. Andrey Tkachenko 2015-09-08

    Not work for widget children. Work only if set module attribute of Alloy tag.
  15. Jason Kneen 2015-09-08

    Why would you add custom tags in a widget?
  16. Andrey Tkachenko 2015-09-08

    @jasonkneen for example: 
        <Widget src="...">
        <Group module="widget.id/tags">
            <Radio value="blackList" title="L(...)"/>
            <Radio value="whiteList" title="L(...)"/>
        </Group>
    </Widget>
    In widget lib folder: 
        function RadioGroup() {
    	this.items = [];
    }
    
    RadioGroup.prototype.add = function(radioItem) {
    	if(!(radioItem instanceof RadioItem)) {
    		throw "Must contains only Radio tag!";
    	}
    	this.items.push(radioItem);
    };
    
    function RadioItem(opts) {
    	_.extend(this, _.pick(opts, 'value', 'checked', 'title'));
    }
    
    RadioItem.prototype.add = function() {
    	throw "Radio tag cant' contains children!";
    };
    
    
    exports.createGroup = function(opts) {
    	return new RadioGroup(opts);
    };
    
    exports.createRadio = function(opts) {
    	return new RadioItem(opts);
    };
    Then use args.children to initialize widget.
  17. Jason Kneen 2015-09-08

    Don't get why you need the widget. Just use the custom tags directly in your app. But I guess you have good reason so good luck!
  18. Andrey Tkachenko 2015-09-08

    Anyway if I can add tags to the widget why I can't use module for this tags ?

JSON Source