@maccesar/titools 2.0.7 → 2.2.1

package/skills/alloy-guides/references/MODELS.md

@@ -1,7 +1,5 @@
 # Alloy Models
 
-## Table of Contents
-
 1. [Overview](#overview)
 2. [Alloy Collection and Model Objects](#alloy-collection-and-model-objects)
 3. [Alloy Data Binding](#alloy-data-binding)
@@ -347,6 +345,8 @@ library.on('change:title', e => {
 This only works if the Backbone method fires the change event and does not enable `{silent: true}` as an option.
 :::
 
+If you want to suppress an update, specify `{silent: true}` in the `options` parameters when calling Backbone methods to change model data. The data-bound view will not be updated to reflect the changes.
+
 ### Bind Deep Object Properties
 
 You can bind deep object properties:
@@ -380,6 +380,16 @@ You can bind models and properties that use names with special characters like d
 </Alloy>
 ```
 
+### Use $.args Values in XML (CLI 7.1.0+)
+
+Since CLI 7.1.0, values passed at creation time can be used directly in XML:
+
+```xml
+<Alloy>
+    <Label text="$.args.foo" />
+</Alloy>
+```
+
 ### Bind Multiple Models to the Same View
 
 You have the ability to bind multiple models to the same view:
@@ -426,6 +436,10 @@ exports.definition = {
 };
 ```
 
+::: warning ⚠️ Warning
+The `transform` method must return **all** bound properties, not just the transformed ones. Until Alloy 1.8.1, simple collection data binding did not require this and automatically fell back to the model attributes.
+:::
+
 ### Lazy Transformation (Performance Tip)
 
 The advantage of defining transformations in the model is that you don't need to repeat them in every controller. A possible disadvantage is that everywhere you bind the model all transformations are computed where you might only need some.
@@ -511,7 +525,7 @@ You need to specify additional attributes in the markup, which are only specific
 * `dataCollection`: specifies the collection singleton or instance to bind to the table. This is the name of the model file for singletons or the ID prefixed with the controller symbol ('$') for instances.
 * `dataTransform`: specifies an optional callback to use to format model attributes. The passed argument is a model and the return value is a modified model as a JSON object.
 * `dataFilter`: specifies an optional callback to use to filter data in the collection. The passed argument is a collection and the return value is an array of models.
-* `dataFunction`: set to an arbitrary identifier (name) for a function call. Use this identifier to call a function in the controller to manually update the view.
+* `dataFunction`: set to an arbitrary identifier (name) for a function call. This is not a declared function in the controller. This attribute creates an alias to access the underlying binding function, which is part of the Alloy data-view binding framework. Use this identifier to call a function in the controller to manually update the view.
 
 Next, create a repeater object (refer to the table above) and place it inline with the view object with the `dataCollection` attribute, or place it in a separate view and use the `Require` tag to import it.
 
@@ -527,6 +541,16 @@ $.win.addEventListener("close", () => {
     $.destroy();
 });
 ```
+
+For global singletons, to properly release them you should also remove event handlers with `off()` and set the reference to null:
+
+```javascript
+$.win.addEventListener("close", () => {
+    $.destroy();
+    Alloy.Collections.book.off();
+    Alloy.Collections.book = null;
+});
+```
 :::
 
 #### Collection-View Binding Example
@@ -634,6 +658,8 @@ In Alloy, a sync adapter allows you to store and load your models to a persisten
 
 Backbone syncs your models to persistent storage devices based on the implementation of the [Backbone.sync method](https://titaniumsdk.com/guide/Alloy_Framework/Alloy_Guide/Alloy_Models/Alloy_Sync_Adapters_and_Migrations.html). Since Backbone's primary use is for web applications, by default, the Backbone.sync method executes RESTful JSON requests to a URL specified by the Model.urlRoot or Collection.url attribute, when these classes are created.
 
+Models are accessed from persistent storage based on the `id` attribute. To override this, set the `idAttribute` property of the model. The `cid` (client ID) is a special property of models that is automatically assigned when they are first created. Client IDs are useful when the model has not yet been saved to the server and does not have its real `id` yet.
+
 The sync method depends on calls to other Backbone methods as described in the table below.
 
 | **Backbone Method**                                              | **Sync CRUD Method** | **Equivalent HTTP Method** | **Equivalent SQL Method** |
@@ -649,7 +675,7 @@ The sync method depends on calls to other Backbone methods as described in the t
 Alloy provides a few ready-made sync adapters. In the 'adapter' object, set the 'type' to use one of the following:
 
 * `sql` for the SQLite database on the Android and iOS platform.
-* `properties` for storing data locally in the Titanium SDK context.
+* `properties` for storing data locally in the Titanium SDK context. You do not need to define the `columns` object in the `config` object. If defined, the object is ignored.
 * `localStorage` for HTML5 localStorage on the Mobile Web platform. Deprecated since Alloy 1.5.0. Use the `properties` adapter instead.
 
 These adapters are part of Alloy and are copied to the `Resources/alloy/sync` folder during compilation. These sync adapters assign the `id` attribute of the models, which means if you assign an ID when creating a model, it is overridden by any sync operations.
@@ -706,11 +732,11 @@ exports.definition = {
 
 **Specify columns property as primary ID**
 
-Define the `idAttribute` key-value pair in the `config.adapter` object to use a `config.columns` key as the primary ID for the SQLite table.
+Define the `idAttribute` key-value pair in the `config.adapter` object to use a `config.columns` key as the primary ID for the SQLite table. If this key is not set, Alloy creates the `alloy_id` column in the table and generates a default GUID as the model ID.
 
 **Specify a migration to use**
 
-Define the `migration` key-value pair in the `config.adapter` object to specify the database version to use. The value of this key is the datatime code of the migration file. Alloy upgrades or rolls back the database based on this value.
+Define the `migration` key-value pair in the `config.adapter` object to specify the database version to use. The value of this key is the datetime code of the migration file. Alloy upgrades or rolls back the database based on this value. If left undefined, Alloy upgrades the database based on the newest migration file.
 
 **Specify a database to use**
 
@@ -718,7 +744,7 @@ Define the `db_name` key-value pair in the `config.adapter` object to specify th
 
 **Specify a database file to preload**
 
-Define the `db_file` key-value pair in the `config.adapter` object to specify the database file ('myfile.sqlite') to preload. Place this file in the `app/assets` directory of your Alloy project.
+Define the `db_file` key-value pair in the `config.adapter` object to specify the database file ('myfile.sqlite') to preload. Place this file in the `app/assets` directory of your Alloy project. Alloy creates a database using the name of the database file minus the file extension if one does not exist.
 
 ### Custom Sync Adapters
 
@@ -734,7 +760,9 @@ The sync adapter exports three functions:
 
 ### Migrations
 
-A migration is a description of incremental changes to a database, which takes your database from version 1 to version X, with a migration file for each step in the evolution of your database schema.
+A migration is a description of incremental changes to a database, which takes your database from version 1 to version X, with a migration file for each step in the evolution of your database schema. This is helpful to keep different versions of a database in sync. For example, when version 7 of your application is deployed, migrations are able to successfully update the database from versions 1 through 6. Currently, migrations are only used with the `sql` sync adapter.
+
+The `migration.up` function upgrades the database from the previous version, while the `migration.down` function rolls back the changes to the previous version.
 
 In Alloy, migrations are defined by JavaScript files located in the `app/migrations` folder of the project. The file should be named the same as the model JavaScript file prefixed with 'YYYYMMDDHHmmss_' (datetime code followed by an underscore), for example, `20120610049877_book.js`. Alloy applies the migrations from oldest to newest, according to the datetime code at the beginning of the file name.
 
@@ -785,7 +813,7 @@ migration.down = migrator => {
 
 #### Migration Rollback Example
 
-Suppose later, you want to include some additional information for your books, such as an ISBN. The below migration file upgrades or rolls back the changes. Since SQLite does not support the DROP COLUMN operation, the migration needs to create a temporary table to hold the data, drop the new database, create the old database, then copy the data back.
+Suppose later, you want to include some additional information for your books, such as an ISBN. The below migration file upgrades or rolls back the changes. Since SQLite does not support the DROP COLUMN operation, the migration needs to create a temporary table to hold the data, drop the new database, create the old database, then copy the data back. Note: if `idAttribute` is not specified, Alloy creates the `alloy_id` column and this column needs to be copied over as part of the migration.
 
 **app/migrations/20130118069778_book.js**
 
@@ -986,7 +1014,9 @@ To use Backbone 1.1.2 to support Alloy Model and Collections objects, open the p
 
 #### Model APIs
 
-**Validation**: Model validation is now only enforced with the `save()` method. Previously, models were also validated with the `set()` method. To force validation when the `set()` method is called, pass `{validate: true}` to the method or extend the Model class.
+**Validation**: Model validation is now only enforced with the `save()` method. Previously, models were also validated with the `set()` method. To force validation when the `set()` method is called, pass `{validate: true}` to the method or extend the Model class. Additionally, validation now occurs even during 'silent' changes (passing `{silent: true}` to methods). Previously, it would not. Failed validations return the `invalid` event. Previously, a failed model validation would return the `error` event.
+
+**Parse Method**: All `parse` methods now run after a `fetch`. You cannot change the `id` of a model during `parse`. The `parse` method receives `options` as a second parameter.
 
 **Other Changes**:
 

package/skills/alloy-guides/references/PURGETSS.md

@@ -1,18 +1,8 @@
 # PurgeTSS
 
-## Table of Contents
-
-- [PurgeTSS](#purgetss)
-  - [Table of Contents](#table-of-contents)
-  - [Overview](#overview)
-  - [Command-Line Interface Usage](#command-line-interface-usage)
-  - [Key Features](#key-features)
-  - [Documentation](#documentation)
-    - [Topics](#topics)
-
 ## Overview
 
-**PurgeTSS** is a powerful Alloy addon designed to enhance the process of developing visually captivating mobile applications for Titanium.
+**PurgeTSS** is an **optional** Alloy addon designed to enhance the process of developing visually captivating mobile applications for Titanium. It is NOT required for Alloy development — many projects use manual TSS styling successfully. Only recommend PurgeTSS when the user explicitly asks about it or their project already uses it.
 
 It offers a range of tools such as customizable utility classes, support for icon fonts, a user-friendly Animation module, a straightforward grid system, and the added convenience of the `shades` command for crafting personalized colors.
 

package/skills/alloy-guides/references/VIEWS_DYNAMIC.md

@@ -1,17 +1,5 @@
 # Dynamic Styles
 
-## Table of Contents
-
-- [Dynamic Styles](#dynamic-styles)
-  - [Table of Contents](#table-of-contents)
-  - [Introduction](#introduction)
-  - [Define Class Styles](#define-class-styles)
-  - [Generate a Dynamic Style](#generate-a-dynamic-style)
-    - [Equivalent Code Outside Controller](#equivalent-code-outside-controller)
-  - [Modify TSS Classes](#modify-tss-classes)
-  - [Autostyle](#autostyle)
-    - [Why Autostyle is Needed](#why-autostyle-is-needed)
-
 ## Introduction
 
 Since Alloy 1.2.0, Alloy supports changing styles dynamically or during runtime. There are two methods to support dynamic styling in Alloy. You can either generate a dynamic style dictionary that can be passed to `applyProperties` or a create method, or modify TSS class styles to an existing component on the fly.
@@ -78,7 +66,7 @@ The previous style sheet defines various class and markup element styles for lab
 
 To generate a dynamic style, use the controller's `createStyle` method by passing it a dictionary with TSS classes. This method returns a dictionary that can be passed to the view object's `applyProperties` method or a create view object method.
 
-You can use the controller's `UI.create` method to create a view component that is dynamically styled.
+You can use the controller's `UI.create` method to create a view component that is dynamically styled. The `UI.create` method accepts the element name (such as `Button`) or the full API name (such as `Ti.UI.Button`). You can optionally add additional properties inline specific to the component in the dictionary parameter.
 
 **app/views/dialog.xml**
 
@@ -168,7 +156,11 @@ Note that code outside of the dialog view-controller is using the instance varia
 
 ## Modify TSS Classes
 
-To modify the TSS classes of an object that has already been created, use the controller's `addClass`, `removeClass` and `resetClass` methods, which adds, removes or resets the TSS classes of a view object, respectively.
+To modify the TSS classes of an object that has already been created, use the controller's `addClass`, `removeClass` and `resetClass` methods, which adds, removes or resets the TSS classes of a view object, respectively. As the classes are modified using these API calls, the view is automatically updated. To take advantage of these APIs, you need to enable autostyle for the components or else the view may not update properly.
+
+::: warning ⚠️ Warning
+Using the `Require` or `Widget` elements to include external views in a controller-less view does not work with the `updateViews` method — you can include the external views, but the styles cannot be updated.
+:::
 
 Pass a reference to the view object as the first parameter, then pass the classes to add or remove as an array or space-separated string as the second parameter. You can optionally specify inline properties as an optional third parameter.
 
@@ -240,3 +232,5 @@ $.removeClass($.label, "coloronly"); // --> appears red and 24dp (not black!)
 ```
 
 With autostyle enabled, the styles update as expected when classes are added or removed.
+
+**Workarounds without autostyle:** If you cannot enable autostyle, you can either create a default class that defines all possible properties (so removing a class reverts to the defaults), or pass in the optional inline properties as the third parameter to `addClass`/`removeClass`/`resetClass` to explicitly set the desired values.

package/skills/alloy-guides/references/VIEWS_STYLES.md

@@ -1,18 +1,5 @@
 # Alloy Styles and Themes
 
-## Table of Contents
-
-- [Alloy Styles and Themes](#alloy-styles-and-themes)
-  - [Table of Contents](#table-of-contents)
-  - [Titanium Style Sheets](#titanium-style-sheets)
-  - [Global Styles](#global-styles)
-  - [Platform-Specific Styles](#platform-specific-styles)
-  - [Custom Query Styles](#custom-query-styles)
-    - [Example Using Custom Properties](#example-using-custom-properties)
-    - [Example Using Conditional Statements](#example-using-conditional-statements)
-  - [Themes](#themes)
-  - [Style Priorities](#style-priorities)
-
 ## Titanium Style Sheets
 
 The Titanium Style Sheets (TSS) file uses a JSON-like syntax to define the attributes of elements in the XML files. All TSS attributes are the properties of the Titanium object.
@@ -171,7 +158,7 @@ As with views, separate styles may be defined based on the platform and device s
 
 **To specify platform or device size conditionals:**
 
-1. Place a set of square brackets (`[]`) directly after the name of the markup element, class name or id name in the TSS file.
+1. Place a set of square brackets (`[]`) **directly** after the name of the markup element, class name or id name in the TSS file. **Do NOT place a space between the name and brackets. The condition statements will be ignored.**
 2. Inside the brackets:
    * `platform` attribute: assign a platform (`android`, `ios`). Comma separate to OR values. Prepend with `!` to negate.
    * `formFactor` attribute: assign a device size (`handheld` or `tablet`).
@@ -203,7 +190,9 @@ Alternatively, create subfolders named as the platform in the `styles` directory
 
 ## Custom Query Styles
 
-You can create custom queries to select which styles to apply in both the TSS and XML files.
+You can create custom queries to select which styles to apply in both the TSS and XML files. Custom query styles override all styles (class, id, and markup element styles), except styles defined as attributes in the XML file.
+
+You may use the `if` attribute in combination with the `platform` and `formFactor` attributes. You can only add **one** custom query to the `if` attribute. The `if` attribute does **not** support multiple queries or the not operator (`!`).
 
 **To use a custom query:**
 
@@ -342,16 +331,16 @@ Themes provide a way to overwrite or modify files for a specific brand of your a
 
 To create a theme, create a folder called `themes` in your Alloy `app` directory. In the `themes` folder, create a folder for your theme.
 
-| Folder or Filename | Merges or Overwrites             |
-| ------------------ | -------------------------------- |
-| config.json        | merges                           |
-| i18n               | merges folders and files         |
-| assets             | merges folders, overwrites files |
-| lib                | merges folders, overwrites files |
-| platform           | merges folders, overwrites files |
-| styles             | merges folders and files         |
-| widgets/\*/assets  | merges folders, overwrites files |
-| widgets/\*/styles  | merges folders and files         |
+| Folder or Filename | Merges or Overwrites             | Supported Since         |
+| ------------------ | -------------------------------- | ----------------------- |
+| config.json        | merges                           | Alloy 1.4.0             |
+| i18n               | merges folders and files         | Alloy 1.4.0             |
+| assets             | merges folders, overwrites files | Alloy 1.4.0             |
+| lib                | merges folders, overwrites files | Alloy 1.7.6 / CLI 5.0.0 |
+| platform           | merges folders, overwrites files | Alloy 1.7.6 / CLI 5.0.0 |
+| styles             | merges folders and files         | Alloy 1.4.0             |
+| widgets/\*/assets  | merges folders, overwrites files | Alloy 1.4.0             |
+| widgets/\*/styles  | merges folders and files         | Alloy 1.4.0             |
 
 To use a theme, add it to your `config.json`:
 

package/skills/alloy-guides/references/VIEWS_WITHOUT_CONTROLLERS.md

@@ -1,13 +1,5 @@
 # Views without Controllers
 
-## Table of Contents
-
-- [Views without Controllers](#views-without-controllers)
-  - [Table of Contents](#table-of-contents)
-  - [Introduction](#introduction)
-  - [XML Markup](#xml-markup)
-  - [Controller Code](#controller-code)
-
 ## Introduction
 
 Views can be created without controllers with an optional style sheet. These views can be used as building blocks to create a GUI. After you have defined your controller-less views, the application can either require in these views using markup or can dynamically generate these views in the controller code.
@@ -55,6 +47,8 @@ Then, the controller can use `$.button1`, `$.button2` and `$.button3` to access
 
 ::: warning ⚠️ Warning
 Unlike other style dictionaries in Alloy, when using the `updateViews()` method, you can only apply styles using IDs. Class and view component styles do not work with this method.
+
+Using the `Require` or `Widget` elements to include external views in the controller-less view does not work with this procedure — you can include the external views, but the styles cannot be updated with the `updateViews` method.
 :::
 
 For example:

package/skills/alloy-guides/references/VIEWS_XML.md

@@ -1,36 +1,5 @@
 # Alloy XML Markup
 
-## Table of Contents
-
-- [Alloy XML Markup](#alloy-xml-markup)
-  - [Table of Contents](#table-of-contents)
-  - [Introduction](#introduction)
-  - [Collection Element](#collection-element)
-    - [Creating a Singleton](#creating-a-singleton)
-    - [Creating an Instance](#creating-an-instance)
-  - [Model Element](#model-element)
-    - [Creating a Singleton](#creating-a-singleton-1)
-    - [Creating an Instance](#creating-an-instance-1)
-  - [Module Attribute](#module-attribute)
-  - [Module Element](#module-element)
-  - [Require Element](#require-element)
-    - [Including Views](#including-views)
-    - [Importing Widgets](#importing-widgets)
-    - [Passing Arguments](#passing-arguments)
-    - [Binding Events](#binding-events)
-    - [Adding Children Views](#adding-children-views)
-  - [Namespace](#namespace)
-  - [Conditional Code](#conditional-code)
-  - [Property Mapping](#property-mapping)
-    - [Proxy Properties](#proxy-properties)
-    - [Android ActionBar](#android-actionbar)
-    - [iOS Navigation Button Shorthand](#ios-navigation-button-shorthand)
-    - [iOS SystemButton Shorthand](#ios-systembutton-shorthand)
-    - [TextField Keyboard Shorthands](#textfield-keyboard-shorthands)
-  - [Event Handling](#event-handling)
-  - [Data Binding](#data-binding)
-  - [Non-Standard Syntax](#non-standard-syntax)
-
 ## Introduction
 
 In Alloy, the XML markup abstracts the Titanium SDK UI components, so you do not need to code the creation and setup of these components using JavaScript and the Titanium SDK API. All view files must be placed in the `app/views` folder of your project with the `.xml` file extension.
@@ -57,8 +26,8 @@ The following table lists the attributes for the UI components:
 
 | Attribute      | Description                                                                                        |
 | -------------- | -------------------------------------------------------------------------------------------------- |
-| `id`           | Identifies UI elements in the controller (prefixed with `$.`) and style sheet (prefixed with `#`). |
-| `class`        | Applies additional styles (prefixed with `.` in the TSS file).                                     |
+| `id`           | Identifies UI elements in the controller (prefixed with `$.`) and style sheet (prefixed with `#`). IDs should be unique per view but are not global, so multiple views can have components with the same ID. |
+| `class`        | Applies additional styles (prefixed with `.` in the TSS file). Overwrites the element style but not the id style. |
 | `autoStyle`    | Enables the autostyle feature for dynamic styling.                                                 |
 | `formFactor`   | Acts as a compiler directive for size-specific view components (`handheld` or `tablet`).           |
 | `if`           | Use a custom query to apply additional styles to the element.                                      |
@@ -200,7 +169,7 @@ exports.createFoo = args => {
 
 ## Module Element
 
-You can also include a view from a native module using the `Module` XML element.
+You can also include a view from a native module using the `Module` XML element. The `method` attribute specifies which creation method to call. If omitted, defaults to `createView`.
 
 **app/views/index.xml**
 
@@ -229,7 +198,7 @@ The `Require` XML element has two uses: including external views and importing w
 
 ### Including Views
 
-Views may be included in other views using the `Require` element. Specify the `type` attribute as `view` and the `src` attribute should be the view file minus the `.xml` extension.
+Views may be included in other views using the `Require` element. Specify the `type` attribute as `view` and the `src` attribute should be the view file minus the `.xml` extension. If you omit the `type` attribute, Alloy assumes it is implicitly set to `view`.
 
 **app/views/index.xml**
 
@@ -255,12 +224,12 @@ aboutView.url = 'http://www.google.com';
 
 ### Importing Widgets
 
-Within a view in the regular Alloy project space (`app/views`), use the `<Widget>` tag to import the widget into the application.
+Within a view in the regular Alloy project space (`app/views`), use the `<Widget>` tag to import the widget into the application. For Alloy 1.4.x and prior, you need to assign the `src` attribute to the widget's name (the `id` in `widget.json`).
 
 **To import a widget:**
 
 1. Copy the widget to the `app/widgets` folder.
-2. Add the `<Widget>` tag in the XML and specify its `src` attribute as the folder name of the widget.
+2. Add the `<Widget>` tag in the XML and specify its `src` attribute as the folder name of the widget. Use the `name` attribute to import a specific view-controller instead of the default `widget.xml`/`widget.js`.
 3. Update the `dependencies` object in the `config.json` file.
 
 **app/views/index.xml**
@@ -385,6 +354,8 @@ For UI objects that belong to a specific platform, use the `platform` attribute:
 <SplitWindow platform="ios"/>
 ```
 
+Additionally, use the alias `Ti` for `Titanium` when specifying namespaces.
+
 Many of the Titanium view proxies not part of the `Titanium.UI` namespace do not require that the `ns` attribute be explicitly set. The following elements are implicitly mapped to a namespace:
 
 | Element          | Namespace     |
@@ -428,7 +399,7 @@ Add the `platform`, `formFactor` and `if` attributes to apply XML elements based
 
 ## Property Mapping
 
-Each Titanium UI object property is defined as an attribute in the XML and TSS file if it accepts a string, boolean, number or Titanium SDK constant.
+Each Titanium UI object property is defined as an attribute in the XML and TSS file if it accepts a string, boolean, number or Titanium SDK constant. Setting properties in the XML overrides the settings in the TSS file. Node text can also be used to define the `Label` text and `Button` title properties.
 
 ```xml
 <Label borderWidth="1" borderColor="red" color="red" width="Ti.UI.FILL">Hello, World!</Label>
@@ -483,9 +454,21 @@ You can set ActionBar properties in the `ActionBar` element.
 </Alloy>
 ```
 
+**app/styles/index.tss**
+
+```javascript
+"#editItem": {
+    showAsAction: Ti.Android.SHOW_AS_ACTION_ALWAYS
+},
+"#actionbar": {
+    displayHomeAsUp: true,
+    icon: "/images/actionicon.png"
+}
+```
+
 ### iOS Navigation Button Shorthand
 
-When specifying either the `LeftNavButton` or `RightNavButton` element, you can define the `Button` attributes directly.
+When specifying either the `LeftNavButton` or `RightNavButton` element, you can define the `Button` attributes directly. This also works with iPad `Popover` objects. Note that you cannot use node text to define the button title with this shorthand.
 
 **app/views/index.xml**
 
@@ -512,11 +495,17 @@ When specifying the `systemButton` attribute, you do not need to use the `Ti.UI.
 
 ### TextField Keyboard Shorthands
 
-When specifying the `keyboardType` or `returnKeyType` for a TextField:
+When specifying the `keyboardType` or `returnKeyType` for a TextField, you can use shorthand constants without the full namespace:
 
 ```xml
 <TextField id="txt" keyboardType="DECIMAL_PAD" returnKeyType="DONE"/>
+<!-- Instead of -->
+<TextField id="txt" keyboardType="Titanium.UI.KEYBOARD_DECIMAL_PAD" returnKeyType="Titanium.UI.RETURNKEY_DONE"/>
+```
 
+This also works in TSS:
+
+```javascript
 "#txt": {
   keyboardType: "DECIMAL_PAD",
   returnKeyType: "DONE"

package/skills/alloy-guides/references/WIDGETS.md

@@ -1,21 +1,5 @@
 # Alloy Widgets
 
-## Table of Contents
-
-- [Alloy Widgets](#alloy-widgets)
-  - [Table of Contents](#table-of-contents)
-  - [Introduction](#introduction)
-  - [Using Widgets](#using-widgets)
-  - [Creating Widgets](#creating-widgets)
-  - [Assets and Libs](#assets-and-libs)
-  - [Configuration](#configuration)
-  - [Controllers](#controllers)
-  - [Models](#models)
-  - [Styles](#styles)
-  - [Themes](#themes)
-  - [Views](#views)
-  - [Widgets](#widgets)
-
 ## Introduction
 
 Widgets are self-contained components that can be easily dropped into Alloy-powered Titanium projects. They were conceived as a way to reuse code in multiple applications or to be used multiple times in the same application. Widgets have their own views, controllers, styles and assets and are laid out the same as the `app` directory in the Alloy project.
@@ -108,7 +92,7 @@ The main TSS file is called `widget.tss` instead of `index.tss`.
 
 ## Themes
 
-Widget themes work the same as project themes except for the placement of the files. Inside your theme folder (`app/themes/<THEME_NAME>`), create `widgets/<WIDGET_NAME>` folders, where `<THEME_NAME>` is the name of the theme and `<WIDGET_NAME>` is the name of the widget.
+Widget themes work the same as project themes except for the placement of the files. Inside your theme folder (`app/themes/<THEME_NAME>`), create `widgets/<WIDGET_NAME>` folders, where `<THEME_NAME>` is the name of the theme and `<WIDGET_NAME>` is the name of the widget. When using a theme, the files in these folders replace the files in the widget's folders.
 
 Create two folders, `assets` and `styles`, to place your custom images and styles for your widget, respectively.
 

package/skills/alloy-howtos/SKILL.md

@@ -25,27 +25,6 @@ This skill automatically detects Alloy projects when invoked and provides CLI an
 - **Not detected** → Indicates this skill is for Alloy projects only, suggests Alloy guides if user wants to migrate
 :::
 
-## Table of Contents
-
-- [Titanium Alloy How-tos](#titanium-alloy-how-tos)
-  - [Project Detection](#project-detection)
-  - [Table of Contents](#table-of-contents)
-  - [Quick Reference](#quick-reference)
-  - [Critical Best Practices](#critical-best-practices)
-    - [Naming Conventions](#naming-conventions)
-    - [Global Events - Use Backbone.Events](#global-events---use-backboneevents)
-    - [Global Variables in Non-Controller Files](#global-variables-in-non-controller-files)
-  - [Conditional Views](#conditional-views)
-  - [Common Error Solutions](#common-error-solutions)
-  - [CLI Quick Reference](#cli-quick-reference)
-  - [Configuration Files Priority](#configuration-files-priority)
-  - [Custom XML Tags](#custom-xml-tags)
-  - [Resources](#resources)
-    - [references/](#references)
-  - [Related Skills](#related-skills)
-
----
-
 ## Quick Reference
 
 | Topic                                        | Reference                                                               |
@@ -198,6 +177,6 @@ For tasks beyond Alloy CLI and configuration, use these complementary skills:
 
 | Task                                     | Use This Skill |
 | ---------------------------------------- | -------------- |
-| Modern architecture, services, patterns  | `alloy-expert` |
+| Modern architecture, services, patterns  | `ti-expert`    |
 | Alloy MVC concepts, models, data binding | `alloy-guides` |
 | SDK config, Hyperloop, app distribution  | `ti-guides`    |

package/skills/alloy-howtos/references/best_practices.md

@@ -2,23 +2,6 @@
 
 This guide provides recommendations for writing Alloy applications. This guide supplements the existing Titanium SDK [Best Practices and Recommendations](https://titaniumsdk.com/guide/Titanium_SDK/Titanium_SDK_Guide/Best_Practices_and_Recommendations/) guide, specifically focusing on Coding Best Practices and Style and Conventions.
 
-## Table of Contents
-
-- [Alloy Best Practices and Recommendations](#alloy-best-practices-and-recommendations)
-  - [Table of Contents](#table-of-contents)
-  - [Titanium-to-Alloy Guidance](#titanium-to-alloy-guidance)
-    - [Loading Libraries in Alloy](#loading-libraries-in-alloy)
-    - [Performance Best Practices](#performance-best-practices)
-    - [Project Organization](#project-organization)
-  - [Coding Style Best Practices](#coding-style-best-practices)
-    - [Naming Conventions](#naming-conventions)
-    - [Global Variables](#global-variables)
-    - [Global Events](#global-events)
-      - [Use Callbacks for Master-Child Communication](#use-callbacks-for-master-child-communication)
-      - [Use Backbone.Events for App-Wide Communication](#use-backboneevents-for-app-wide-communication)
-
----
-
 ## Titanium-to-Alloy Guidance
 
 ### Loading Libraries in Alloy

package/skills/alloy-howtos/references/cli_reference.md

@@ -2,28 +2,6 @@
 
 The Alloy CLI is a command-line tool for managing and building Alloy projects.
 
-## Table of Contents
-
-- [Alloy Command-Line Interface Reference](#alloy-command-line-interface-reference)
-  - [Table of Contents](#table-of-contents)
-  - [Installation](#installation)
-    - [Manual Installation](#manual-installation)
-    - [Bleeding Edge Installation](#bleeding-edge-installation)
-  - [Commands](#commands)
-    - [new](#new)
-    - [generate](#generate)
-      - [Model Format](#model-format)
-    - [install](#install)
-    - [compile](#compile)
-    - [run](#run)
-    - [i18n-extract](#i18n-extract)
-    - [copy](#copy)
-    - [move](#move)
-    - [remove](#remove)
-  - [Additional Options](#additional-options)
-
----
-
 ## Installation
 
 The Alloy CLI is automatically installed when installing the `alloy` package.
@@ -53,7 +31,7 @@ cd alloy
 
 ### new
 
-Creates a new Alloy project on an existing Titanium project.
+Creates a new Alloy project on top of an existing Titanium project (create the classic Titanium project first, then run this command from inside the project directory).
 
 ```bash
 alloy new [<project_path>] [<project_template>] [--force] [--no-colors]