{ "id": "62135", "key": "TIMOB-1503", "fields": { "issuetype": { "id": "1", "description": "A problem which impairs or prevents the functions of the product.", "name": "Bug", "subtask": false }, "project": { "id": "10153", "key": "TIMOB", "name": "Titanium SDK/CLI", "projectCategory": { "id": "10100", "description": "Titanium and related SDKs used in application development", "name": "Client" } }, "fixVersions": [], "resolution": { "id": "7", "description": "", "name": "Invalid" }, "resolutiondate": "2017-04-28T20:50:41.000+0000", "created": "2011-04-15T02:54:33.000+0000", "priority": { "name": "Low", "id": "4" }, "labels": [ "errors", "jslint", "kitchensink" ], "versions": [], "issuelinks": [], "assignee": { "name": "ingo", "key": "ingo", "displayName": "Ingo Muschenetz", "active": true, "timeZone": "America/Los_Angeles" }, "updated": "2017-05-02T21:12:14.000+0000", "status": { "description": "The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.", "name": "Closed", "id": "6", "statusCategory": { "id": 3, "key": "done", "colorName": "green", "name": "Done" } }, "components": [ { "id": "10206", "name": "iOS", "description": "iOS Platform" } ], "description": "{html}
When I open KitchenSink application in Eclipse (JavaScript\nedition) it shows 151 errors and 427 warnings. As the baseline\nsample app, this seems like it should be fairly clean as it could\nadd subtle errors to users code as they use elements of this code\nas a starting point. Also, I have found a number of files in the\nkitchensink application which are no longer used.
I have created a patch to reduce the number of warnings down to\nthree, a more reasonable number. I agree, having a kitchensink app\nwith so many warnings is not very confidence-inspiring.
How do we apply this patch to KS project files on Mac OS\nX/Titanium?
This is assuming you have cloned the git project.
\nIf that says the patch is OK then apply it:
\n3. git-apply kitchensink.diff
NOTE: I created a new, separate project called\nPatchedKitchenSink and copied the patched KitchenSink/Resources dir\ninto it, overwriting the base Resources dir that Titanium created.\nThe files around the checked-out version (like what is in build/)\nare not well.
Step 1 should read:
\nSorry about that.
I get the following errors. Can you just put a zip of the\nupdated files up somewhere?
\n\n$ git apply kitchensink.diff \nkitchensink.diff:821: trailing whitespace.\ntestRow(\"integer\", \"123\", function(obj) { return obj==123; });\nkitchensink.diff:822: trailing whitespace.\ntestRow(\"double\", \"123.456\", function(obj) { return obj == 123.456; });\nkitchensink.diff:1766: space before tab in indent.\n Titanium.API.info('search bar: focus received');\nkitchensink.diff:1771: space before tab in indent.\n Titanium.API.info('search bar:blur received');\nkitchensink.diff:1856: space before tab in indent.\n {\nerror: patch failed: KitchenSink/build/iphone/Resources/.version:1\nerror: KitchenSink/build/iphone/Resources/.version: patch does not apply\nerror: patch failed: KitchenSink/build/iphone/project.xcconfig:1\nerror: KitchenSink/build/iphone/project.xcconfig: patch does not apply
\n
And just to be verbose, here's what happens with a --check:
\n\n\n$ git apply --check kitchensink.diff \nerror: patch failed: KitchenSink/build/iphone/Resources/.version:1\nerror: KitchenSink/build/iphone/Resources/.version: patch does not apply\nerror: patch failed: KitchenSink/build/iphone/project.xcconfig:1\nerror: KitchenSink/build/iphone/project.xcconfig: patch does not apply
\n
It may be that the current version is newer than what is in the\npatch.
Do we even care about this? Going to put in Ralf's bucket.
I would like to request that, as the primary coding\nmodel and de facto Ti reference and teaching piece for all current\nand aspiring Titanium developers, Appcelerator should make it a\npriority item for improving the quality of the code and its\nembedded documentation. There is really no excuse for providing a\nreference app that generates hundreds of errors and warnings, since\nthey can be avoided. Many of the examples need to be more robust,\nand the code quality is less than optimal, to say the least.\nThere's little use of user-defined classes, the examples are in\nsome cases overly trivial and unhelpful, there's a lot of redundant\ncode with hardwired coordinates, etc. I would think that\nAppcelerator would want this to be a \"best foot forward\"\nadvertisement for the platform, using coding best practices. It's\nbeen 6 months since this was raised, and I'm still getting 155\nwarnings from KS in 1.6.0.
I couldn't agree more. KitchenSink is a mess, both in structure\nand coding style.
\nIt is important. Every new user use KitchenSink as a reference.\nSo you're essentially promoting bad coding style.