[TIMOB-16984] TiAPI: Deprecate Ti.include
| GitHub Issue | n/a |
|---|---|
| Type | Improvement |
| Priority | Medium |
| Status | Closed |
| Resolution | Fixed |
| Resolution Date | 2014-06-23T17:18:28.000+0000 |
| Affected Version/s | Release 3.2.3 |
| Fix Version/s | Release 3.3.0 |
| Components | TiAPI |
| Labels | n/a |
| Reporter | Malcolm Hollingsworth |
| Assignee | Ingo Muschenetz |
| Created | 2014-05-15T12:36:48.000+0000 |
| Updated | 2014-08-12T20:22:23.000+0000 |
Description
The Ti.include method was a solution fit for another time in Titanium's history. That time has long since gone. Too many newbies are using Ti.include as if it is the correct pattern to develop their apps against.
The only reason against deprecation is that some older apps still use Ti.include. However using this as a reason only serves to increase the number of apps this will affect.
Moving this ticket to engineering for further evaluation and prioritization. This ticket was originated based on the community discussion around relevance of Ti.include.
[~bhatfield] does anything else need to be done to show this as "deprecated" in Studio warnings?
"Titanium.include" shows as deprecated in Studio content assist. "Ti.include" does not show any content assist. Both "Ti.include" and "Titanium.include" do not show anything in console during build or app run.
Verified on Titanium SDK: 3.3.0.v20140711123603 AppC Studio: 3.3.0.201407111535 The content assist shows deprecated for both Ti.include and Titanium.include. However, no deprecated message is shown in console when app is build and run on Android or iOS.
Maybe it is too late. But this depreciation really effects the ability to use third party JS libraries. Of course they can be wrapped, but by depreciating an include mechanism it means the "original" file needs to be edited. At present I can Ti.include a third party JS library into my own commonJS module and then happily write over the third party library when ever updates are released. I am not sure how policing against bad user coding in this one particular instance helps.
BTW I understand the currently problems with Ti.include but fixing those and making it a true include would be better. Maybe something in alloy that acts more like a c-preprocessor would be the way to go
Ti.include() should have never existed. If you really, really need similar functionality, then consider a workaround like this:
function include(file) { return eval(Ti.Filesystem.getFile(Ti.Filesystem.resourcesDirectory, file).read().text); }Thank you Chris. I completely agree that the included script should not be imported into the global space and this work around does the trick. What I was suggesting was for Ti.include to be fixed to work like this rather than how it did originally
[~ndastur], I was waiting for dev response to your comment. Since this feature was implemented and validated, we were waiting until the end of the cycle to close. I noticed your comment as I was about to do that. I will close this ticket now, but if you feel there would be benefit from an improvement in this area, please write a new improvement or feature ticket. Thanks, your friendly QE team.