Sencha Touch WORK Download For Mac

Create a file '.senchasdk' in your project folder and in it simply type sdk and save... In your project folder ensure that your framework files such as sencha-touch.js, debug.js etc are in the sdk folder

First create a dummy project using sencha generate app lets say demo...Go to the demo folder you will find a sdk folder there copy that and put it in your current project folder then try sencha command in your project folder again...

Reason for that error is because when you type sencha command in your project folder it searches for a node.js file inside the sdk folder i think the path is sdk/command/node.js or something(dont remember)... Probably in your current sdk folder the file is not present...

The .sencha/app/build-impl.xml file contains the root of the generated build script (as it always has for a Sencha Cmd generated app). This file, however, has been refactored into several smaller scripts. This makes understanding the build process much simpler compared to the single, large XML file in previous releases.

The sencha app refresh command now routes to the new refresh target and this target is automatically invoked by the build. This means you no longer need to run sencha app refresh and sencha app build to get your app ready for "dev mode". In other words, sencha app refresh is just a subset of a full build and you can run that command if all you need to do is update metadata such as loader paths or class aliases.

This extra build step (unlike all of the other build steps) is disabled by default because it adds several seconds to the build time. To enable this build step, add the following to .sencha/app/build.properties:

The properties for the build are much more completely listed and documented in .sencha/app/defaults.properties. You can override these in .sencha/app/build.properties or, depending on build environment, .sencha/app/production.properties or .sencha/app/testing.properties.

Your app build will run and then Cmd then will pause waiting for any changes you might make. When changes are detected only the minimum amount of work necessary is performed to bring your app and its CSS up to date, saving you from having to manually run sencha app refresh or rebuilding your Sass.

This maintenance release contains improvements and fixes for many issues reported by our friend in the community. Many issues relate to the whole sencha app upgrade process, the meaning of "merge conflicts" and cases where Cmd did not handle those conflicts cleanly. Framework Packages Packages were introduced in Sencha Cmd 3.1.0. In that release, there was only one location for packages and that was set by workspace.package.dir to be ${workspace.dir}/packages. This meant that Ext JS 4.2's (many) packages would be copied to that folder. In this release, frameworks can now contain their packages and these are no longer copied out of the framework when the framework is introduced to the workspace. This detail was handled by Sencha Cmd, so this applies to Ext JS 4.2.0 as well as Ext JS 4.2.1. This is handled during framework upgrade and Sencha Cmd will remove the framework's packages from the workspace.packages.dir. Upgrades The general method for upgrading an application is sencha app upgrade and while that remains true in this release, you now have more control over the process. If you have multiple applications in a workspace, for example, you need to decouple the framework and application upgrades. By default, sencha app upgrade now operates as if you specified sencha app upgrade --noframework and proceeds to upgrade the current application to the current framework. This presupposes that you have already upgraded the framework as part of a upgrading a different application in the workspace. If you have created packages, you can upgrade them like so from the package folder:sencha package upgrade NOTE: If you are not upgrading frameworks, you may have to manually delete the "ext-*" packages from the "packages" folder and the "ext" folder as well. Then run the following to copy the framework and packages to the workspace:sencha -sdk /path/to/extjs generate workspace . app.js The majority of upgrade issues revolved around the "app.js" file. In previous releases, Sencha Cmd would add entries to "app.js" during code generation calls like sencha generate model (but also for controllers and the rest). Further, the location of this file differed by framework. Due to the complications this approach creates and the fact that often these updates are not wanted on the application, these commands no longer update"app.js". You will need to add the newly created controllers, views, stores, etc. to the appropriate class. In many cases this will be on one of your controllers and not your application. To make applications consistent across frameworks, and compatible-by-default with Sencha Architect, "app.js" now resides in the root folder of generated applications. The sencha app upgrade command will move this file from the "app" folder for Ext JS applications. Merge Conflicts With Sencha Cmd 3.0, we introduced tracking of generated code to allow upgrades to reconcile changes you may have made with changes to the "standard" flavor of certain key files. This is tracked in ".sencha/app/codegen.json". When generating code, if there is a file in the way, Cmd will use this data to do a 3-way merge with the version Cmd originally produced as the base, the version in the way as "Custom" and the new version as "Generated". In the case of overlapping changes, Cmd will report s "MERGE CONFLICT" in the log and write the standard (at least to many source control systems) conflict indicators in the file:> Custom In this release we have fixed several cases where merge conflicts were falsely reported during sencha app upgrade (which regenerates certain core files like "app.js") and cases where subsequent steps of the upgrade would wrongly try to use a file containing merge conflicts. There are two strategies for handling merge conflicts: Your source control comparison tools Call a merge tool of your choice during the upgrade process to resolve conflicts as they occur. The use of source control to review the resulting changes from an upgrade is not new. The best practice here (as always) is to perform upgrades with a clean working tree (no pending changes). This will allow you to discard or revert whatever you need. Using a Third-party Merge Tool New in this release is the ability to configure an external merge tool to be called during the upgrade process. You can do this in a personal configuration file in your HOME directory. For example: C:\Users\Me>md .senchaC:\Users\Me>cd .senchaC:\Users\Me\.sencha>md cmdC:\Users\Me\.sencha>cd cmdC:\Users\Me\.sencha\cmd>notepad sencha.cfg For example, you add these entries like those below to use the Perforce Visual Merge tool:cmd.merge.tool=C:\\Program Files\\Perforce\\p4merge.execmd.merge.tool.args=${cmd.merge.tool.args.p4merge} For further details, consult the comments in the "sencha.cfg" file in your install folder of Sencha Cmd. The support for personal Sencha Cmd configuration files is also documented in that same file. New Features Compiler (2) SDKTOOLS-449 Compiler should support allow stdout as an output target SDKTOOLS-476 Compiler -classpath switch should allows tags to be added to the files in the path Misc (2) SDKTOOLS-389 The framework should be able to add to the workspace repository for app builds SDKTOOLS-448 Cmd should load per-user and version-independent config files in addition to base configuration Total: 4 Bugs Fixed Build (4) SDKTOOLS-384 Package build needs to produce package-all.scss file for non-theme packages SDKTOOLS-446 Application commands should warn instead of fail when Cmd version does not match exactly SDKTOOLS-450 Sencha.cfg properties are not overrideable via ant "-D" switches SDKTOOLS-477 Default help target for applications and packages should not require that Ant be in the PATH Compiler (4) SDKTOOLS-383 Application build should include package SASS variables in (forward) dependency order SDKTOOLS-461 Auto-dependency scanner does not recognize ftype and ptype references SDKTOOLS-462 Auto-dependency scanner does not recognize "defaults" object configuration SDKTOOLS-475 Compiler 'circular requires' error should be downgraded to a warning Generator (2) SDKTOOLS-483 Paths for manifest.js and shortcuts.js are incorrect in a app's theme.html file SDKTOOLS-486 App generation needs to preserve Architect-generated files Misc (11) SDKTOOLS-281 Preprocessor option "feature logger" cannot be controlled by build properties SDKTOOLS-297 Generated app.js file contains redundant loader configuration SDKTOOLS-360 sencha app upgrade --noframework can produce false merge conflicts SDKTOOLS-367 When generating a Touch app, the Loader's path to the framework is wrong SDKTOOLS-392 App builds for all frameworks/versions should consistently use build.properties SDKTOOLS-414 No error message indicating that embedded version of Compass/Sass require Ruby 1.8 or 1.9 SDKTOOLS-421 App build process skips resource copy under certain conditions SDKTOOLS-443 Commented out script tags can break page compiler SDKTOOLS-445 Required package properties are not inherited by secondary packages during builds SDKTOOLS-447 System proxy settings are not picked up by upgrade or package commands SDKTOOLS-480 sencha app upgrade from Touch 2.1 to 2.2 misses some files Sass (1) SDKTOOLS-426 Themes cannot control the image paths if they are not built using Cmd Slicer (1) SDKTOOLS-478 Screenshot-runner has invalid check for duplicate slicer paths Upgrade (2) SDKTOOLS-460 sencha app upgrade will corrupt certain files after detecting a merge conflict SDKTOOLS-484 Touch app upgrades generate merge conflicts Total: 25 Known Issues Compiler (1) SDKTOOLS-327 Sencha Touch applications cannot use optimizer Misc (1) SDKTOOLS-487 app refresh creates empty folder Total: 2 Release Notes for Sencha Cmd 3.1.1 Date: April 5, 2013 Version Number: 3.1.1.274 Windows - Mac OS X - Linux/64 - Linux/32 2b1af7f3a8

Sencha Touch WORK Download For Mac

Join our mailing list