[kylemwhite]

Yes, I realize now that it's always been its own object (or class), so.... non-issue.
Yes, the only issue is that the static methods should be called staticMethod instead of classMethod because isA is an object and not a class.

[Isomorphic]

isA methods have been changed to staticMethods in the latest builds of 12.0d.

[kylemwhite]

I see a lot of changes, especially with defining types, which is good. It has broken my generator for now, but that's ok. I am removing lots of special cases from the code which is great. With these changes, I am encountering a few new errors but I think they're easy fixes so instead of writing special cases to handle them, I'm hoping to just get them fixed in ref docs.

1. Why define boolean as a type? It's already a Javascript primitive. The way it's defined, it basically tries to make boolean equivalent to Boolean, which is not the case in Javascript. I would just have to remove it.

2. Using Integer, integer and int interchangeably. How about picking one and sticking with it? I vote for Integer because it's descriptive and types usually start with a capital.

3. <docItem ref="type:HTMLString" type="type" description="A String of HTML,..." name="HTMLString" baseType="string"></docItem> <-- Should be String?

4. SCImgUrl and SCImgURL should have the same casing everywhere (unless they are two different types, but I doubt that).

5. ValidatorConditionCallback, GetFieldValueCallback and ValidatorActionCallback are methods on the Callbacks class but they are used as types in the DataSourceField, ValidatorDefiniton and Validator classes. Can these be defined as types? I'm not sure what that would look like in the ref docs but in TypeScript it would look like this:

export type ValidatorConditionCallback = (item: DataSourceField | FormItem, validator: Validator, value: any,  record: any) => boolean;

[Isomorphic]

With Boolean vs boolean, Integer vs int we are conveying primitive vs object type, as in Java. So the lowercase variants mean no nulls. The docs explain this as well.

We'll check on whether there are letter case issues (3 and 4).

By defining those Callbacks as methods on the Callback object you get a full @method definition, which you should be able to translate to a TypeScript definition as you can with any of our other method definitions.

[kylemwhite]

Booleans: Understand that Boolean can be null whereas boolean cannot. However, boolean conflicts with the JavaScript primitive type boolean so it cannot be declared as an additional type in TypeScript. I will just ignore it. The only loss is that there's not a way (that I can think of yet) to attach the 'not null' documentation to the primitive boolean type and TypeScript cannot enforce the 'not null' rule but that's no worse than JavaScript so not a big deal.

Ints: Understand that Integer allows nulls whereas int does not. How about integer? I don't see a definition for that but it is used a lot (I get 205 hits when I do a case-sensitive search).

Callbacks: Generally @method definitions are not used as types (if I'm wrong about that, please give me an example as I may have a misunderstanding). However, I understand that Callbacks is special and its purpose is to define method definitions as types so I'll make it work.

[Isomorphic]

We've covered Boolean vs boolean, Integer vs int before: our recommendation remains that, since the distinction can't be directly represented in TypeScript, that the generated API included a generated phrase like "Cannot be null" so the developer doesn't miss out on the information.

We'll check on uses of "integer" (not capitalized).

@methods on the Callback object do get used as types: previously we were using them as types for params (eg Callbacks.LoadScreenbCallback et al), and now in a couple of places as the types for attributes where a String expression or Function can be supplied. It seemed the clearest way to provide a definition for the expected behavior of the Function that can be supplied.

[kylemwhite]

RE: BOOLEANS

boolean is a JavaScript primitive type.

In JavaScript, it can contain the values true or false. It can be assigned other values such as undefined or null (or a string or whatever) but its type will change. But, since there's no type checking in JavaScript, nothing breaks until (maybe) runtime. In JavaScript, boolean can not be redefined. Same with TypeScript.

In TypeScript, if strictNullCheck="false", then boolean can be true, false, undefined or null. If strictNullCheck="true", then boolean can only be true or false.

Thus, setting strictNullCheck="true" in TypeScript accomplishes the goal of limiting boolean to true or false.


from https://developer.mozilla.org/en-US/...bjects/Boolean

In JavaScript, the Boolean object is an object wrapper for a boolean value.
Any object of which the value is not undefined or null, including a Boolean object whose value is false, evaluates to true when passed to a conditional statement. For example, the condition in the following if statement evaluates to true:

var x = new Boolean(false);
if (x) {
  // this code is executed
}

This is probably not the intended behavior of Boolean in SmartClient (or is it?)

JavaScript IS TypeScript, thus the Boolean in TypeScript behaves the same as the Boolean in JavaScript unless strictNullCheck="true".

With strictNullCheck="true", the Boolean object can no longer be set to undefined or null and this would violate the ISC definition of Boolean.

So, in order to obtain the functionality documented for boolean and Boolean without trying to redefine JavaScript types, I am now doing the following:

1. Set strictNullCheck="true". This is actually not defined in the typedef library, it is (usually) defined in the tsconfig.json file for a TypeScript project. Somewhere in the documentation, I will recommend to the developer that they use strictNullCheck="true" but that will be the developer's choice.
2. boolean will remain unaltered. You can't redefine it anyway. With strictNullCheck="true", it will be limited to true or false.
3. Boolean types will be mapped to boolean | null as described in the ISC documentation. This will allow the value to contain true, false or null as intended and still behave like a boolean (not like an object).

This effectively eliminates the JavaScript Boolean object from SmartClient but I think that's ok because ISC is not defining any new functionality for it anyway.

If a developer does not use strictNullCheck="true", then he/she may have code that sets boolean values to null or undefined... although it will still be documented that they should not do that.
Items defined as Boolean will also be able to take the value undefined, which is not the intent but again, the documentation will discourage that.

Similarly, items of type Number have been generated to be Number | null so that they can be null even when strictNullChecks="true" and conform to the ISC system. Note that they are not replaced with number | null because if Number is specified, then it is implied that the extensions on Number are available, which wouldn't be the case if number was used.

number will remain a JavaScript primitive type which, when strictNullCheck="true", will not allow undefined or null. This is not defined in the ISC docs (and doesn't need to be) but I'll bet that if it was, it would be similar to boolean in that it is not intended to hold the values null or undefined.

This method not only documents the intended behavior in the property type definitions (i.e. | null is explicit), it actually leads to enforcement of the intended behavior (when strictNullChecks="true"). It should be noted, however, that there are many cases of subclasses defining properties and methods with types/signatures different than the parent class (even casing differences count because boolean is not the same as Boolean) preventing generation of properties and methods. I know that sometimes this is by design but I suspect that most of them are just inconsistencies. For those that are inconsistencies, they should be easy to fix. For those that are intentional, I'm still working on a way to deal with that but I'd like to get rid of the inconsistency cases first to see how many we're dealing with. They are, of course, all documented in the errors.txt file.

[Isomorphic]

As we've covered, we did not intend to define a new JavaScript primitive type, rather, boolean vs Boolean is just a documentation convention that indicates whether null is allowed. Using this convention eliminates a lot of redundancy.

Glad you figured out how to best represent whether null is allowed in TypeScript.

If there are any inconsistencies left with boolean vs Boolean in subclasses, we'd recommend allowing null.