[kylemwhite]

Agreed, should be in the TypeScript documentation. Is this just one case of a more general rule though? I seem to recall (but not specifically offhand) that there are other things that are created by defining an array of plain old JavaScript objects, some of which might have specific types associated with them.

[Isomorphic]

There are ListGrid, TreeGrid and DetailViewer fields, but these do not have subtypes. There are also some cases in which it would come up in the Dashboards and Tools system. We would recommend discussing it as needed for DF.items, but applicable to other cases, such as where Canvas Properties are specified and you want to use type-checking for ListGrid properties.

[kylemwhite]

This page: http://www.smartclient.com/smartclie....TileGrid.data says that the setter for TileGrid.data is TileGrid.setData(). However, there does not seem to be a TileGrid.setData() in the docs. Is it just missing from the docs?

[Isomorphic]

Technically not needed since it is a setter, hence can be called via setProperty("data"). But for clarity we'll add a short doc for it.

[kylemwhite]

There's a class called MathFunction with a couple static methods (getDefaultFunctionIndex(), getRegisteredFunctionIndex ()) that return an 'Index' but there is no documented type (or object or class) called 'Index'. So, what is an Index?

[kylemwhite]

BooleanItem extends CycleItem but CycleItem is not documented.

[kylemwhite]

Same thing with RelationItem, ScrollingMenu... referenced as base classes but not documented.

I'm getting close to 100% class coverage.

[kylemwhite]

RichTextItem defines the colSpan property defining it as number | string. This overrides the base FormItem colSpan which is defined as simply number. I understand that sometimes there is a reason to override a property with a different type but in this case is there a reason? Same goes for ToolbarItem.

[kylemwhite]

WOAH!!!!

Yes, I noticed. typescript="true". String constants are all defined. Please let me know the plan. Thanks.

[Isomorphic]

Yes, all constant values that are specified in the docs as eg isc.Canvas.HIDDEN can now be looked up in the referenceDocs.xml file, so no more guesswork.

[kylemwhite]

This is definitely good news, although it does bring up some questions:

1. Previously, when generating types, I was not looking at the baseType attribute (I was using it for properties and method parameters). With the introduction of Constant, I realized that I should look at the baseType because Constant has a baseType='string' which is what it is.... Great. Now I am looking at the baseType when generating types but that messed me up because a Callback has a baseType='string'. Well, I know that in some cases a Callback can be specified as a string but it is not fundamentally a string. So, I've put a new rule in to make sure that Callback is still specified as any. I think a better way to handle it would be to leave the baseType off from Callback and in the cases when a parameter can take an actual Callback or a string, it should be defined as: Callback | string.

2. Now that I'm looking at the baseType attribute for types, I came across a baseType='Identifier' (for GlobalId) and baseType='SCImgURL' (for SCSpriteConfig). I thought baseType would only ever be string, and if it was expanded, it would be some other actual JavaScript type (number, boolean, object etc.) If baseType is going to take on other made-up types, it loses (what I thought was) its purpose which is to map an ISC type back to the fundamental JavaScript type for code generation.

3. There are several types which probably should have a baseType='string' such as:

1. KeyName - Strings to identify the various keys on the keyboard.
2. RelativeDateShortcut - A RelativeDateShortcut is a special string ...
3. AutoTestLocator - An autoTestLocator is an xpath-like string ....

4. What is the purpose of the typescript='true' attribute? I like the fact that you're considering TypeScript in the referenceDocs.xml file but I'm not sure how to use it yet. Should I refrain from including items that do not have the attribute? Or is this the start of a bigger effort to support TypeScript?

[kylemwhite]

Are these supposed to be blank?:

• ref="classAttr:StatefulCanvas.STATE_UP"
• ref="classAttr:StatefulCanvas.UNSELECTED"

[Isomorphic]

1. we'll check on this

2. you are intended to look at the baseType for the other type, and you'll ultimately arrive at string or some other atomic type (right now they are all string however)

3. we'll check on these

4. this might have slipped through form internal processing, we'll look at it

Yes, those states are supposed to be blank.

[kylemwhite]

1. Great, thanks.

2. I've really got to question the thinking on this one. Why make a code generator go through hoops to back-track to the atomic type? This is not meant as a sub-classing system. It's just meant to aid in code generation and the easiest thing to do for code generation is to just put in the atomic type.

3. Great, thanks.

4. Ahhhh... so that might just be an intermediate value, ok. I'll just ignore it.

[Isomorphic]

We've made some changes to address the issues related to the undocumented classes: CycleItem, RelationItem and ScrollingMenu. As well as the issue related to the type of the 'colSpan' property. Please try the next nightly build, dated August 11.

Regards
Isomorphic Software