/ext-4.0.7/jsbuilder/README.md

https://bitbucket.org/srogerf/javascript · Markdown · 203 lines · 151 code · 52 blank · 0 comment · 0 complexity · 902031206e3375024701f6abb7d4e1d7 MD5 · raw file

  1. #What's new
  2. ##Loader
  3. To init the Loader, assuming PATH points to the root folder
  4. load(PATH + 'src/Loader.js');
  5. Loader.setBasePath(PATH + 'src');
  6. After that, simply include other classes at will. The behaviour should be similar to require_once in PHP. It is specially useful when you need to include dynamic components during run-time without having to specify all of them at the beginning. For example:
  7. // Single class
  8. Loader.require('Filesystem');
  9. Fiesystem.readFile('some/file/here.js');
  10. // Multiple
  11. Loader.require(['Filesystem', 'Logger', 'Parser']);
  12. // Class name syntax
  13. Loader.require('Some.Thing.Here'); // Will load Some/Thing/Here.js within the basePath set above
  14. This is beautifully utilized by the Parser below to dynamically load Statement classes on demand.
  15. ##Parser
  16. ###Introduction
  17. The new Parser allows fully customizable build, to be consumed by all of our products. It combines the syntax of inline JavaScript comments & HTML for high readablity. As a quick example, let say we have this chunk of code:
  18. alert('Some code here');
  19. //<if browser="ie" browserVersion="6">
  20. alert("Some ugly hacks just to target IE 6 only");
  21. //<else>
  22. alert("Others");
  23. //</if>
  24. During build time, if we supply the following params:
  25. browser: 'ie'
  26. browserVersion: 7
  27. The result will be:
  28. alert('Some code here');
  29. alert("Others");
  30. ###Nested conditions
  31. Nested conditions / tags are fully supported without sacrificing much build performance. We can mix and match complex conditions when necessary:
  32. //<if condition="here">
  33. //<debug>
  34. //<if blah>
  35. ...
  36. //</if>
  37. ...
  38. //</debug>
  39. ...
  40. //<if other="cond">
  41. ...
  42. //<else>
  43. //<deprecated since="1.0">
  44. ...
  45. //</deprecated>
  46. ...
  47. //</if>
  48. //</if>
  49. ###Attribute Syntax
  50. Currently all these are supported:
  51. browser="ie"
  52. browser='ie'
  53. browser=ie
  54. Comparisons:
  55. browser="6"
  56. browser="!6"
  57. browser=">6"
  58. browser="<6"
  59. browser=">=6"
  60. browser="<=6"
  61. Auto casting during evaluation
  62. Boolean: "true" => true, "false" => false
  63. Numeric: "3.2" => 3.2
  64. ###Tag Name:
  65. Parser package is designed to be highly extensible. All custom tag names have their own corresponding class, extending from Parser.Statement (Parser/Statement.js). Currently we have the following:
  66. If
  67. Elseif
  68. Else
  69. Debug
  70. Deprecated
  71. Debug and Deprecated extends from If, and they make typing more convenient:
  72. //<debug>
  73. alert("Stuff in here are strictly for debugging, shouldn't appear during production");
  74. //</debug>
  75. Which is equivalent to:
  76. //<if debug="true">
  77. ...
  78. //</if>
  79. // OR
  80. //<if debug>
  81. ...
  82. //</if>
  83. Deprecated has a required "since" attribute:
  84. //<deprecated since="2.0">
  85. alert("Old stuff for backwards compatibility");
  86. //</deprecated>
  87. If the param name "minVersion" (minimum supported version) is set to 3.0 (>2.0) during build, the above will disappear for good.
  88. Unknown tags (no equivalent classes that the Loader can find) will be ignored
  89. //<notSupportedYet>
  90. alert("Nothing special")
  91. //</notSupportedYet>
  92. Furture tags can be added with ease based on our needs. This is how Parser.Statement.Debug looks like:
  93. Loader.require('Parser.Statement.If');
  94. Parser.Statement.Debug = Ext.extend(Parser.Statement.If, {
  95. constructor: function() {
  96. Parser.Statement.Debug.superclass.constructor.apply(this, arguments);
  97. this.setProperty('debug', true);
  98. }
  99. });
  100. ###Inversion
  101. For convenience, conditional inversion can be done like this:
  102. //<!if browser="ie">
  103. //</!if>
  104. //<!debug>
  105. //<else>
  106. //</!debug>
  107. ###Standalone
  108. Parser is a singleton and does not depend on anything else other than Loader.js and Ext.js. It's unittest-able too. Usage is straight-forward:
  109. Parser.setParams({
  110. debug: false,
  111. minVersion: 2.2,
  112. ie6Compatible: false
  113. // More params...
  114. });
  115. // Returns the parsed content of the given file, based on the params supplied above
  116. var parsed = Parser.parse("path/to/file.js");
  117. ###Integration with building process
  118. Parser will automatically process final target files right before compression. It takes the "options" property inside jsb3 file as the params, merged with the old "debug" property. For example, currently in ext-touch.jsb3:
  119. ...
  120. "builds": [
  121. {
  122. "name": "Sencha Touch",
  123. "target": "ext-touch.js",
  124. "debug": true,
  125. "packages": [
  126. ...
  127. ]
  128. }
  129. To supply more params for Parser:
  130. ...
  131. "builds": [
  132. {
  133. "name": "Sencha Touch",
  134. "target": "ext-touch.js",
  135. "debug": true,
  136. "options": {
  137. "minVersion": 2.0,
  138. "experimental": true
  139. }
  140. "packages": [
  141. ...
  142. ]
  143. }
  144. From which the Parser will process with the following params:
  145. {
  146. debug: true,
  147. minVersion: 2.0,
  148. experimental: true
  149. }
  150. ###Unit testing
  151. /path/to/jsdb tests/run.js --name parser