[Isomorphic]

You may have noticed a ton of additional fixes going in, in particular, we've cleared up a bunch of instances of string-based types (like Identifier) which were described in prose as strings but not explicitly declared to be strings, attribute vs setter disagreements which could not be programmatically reconciled, etc.

There's one additional item in Errors.txt we can't figure out - what's this? There's nothing we can find in referenceDocs.xml that looks like this.

Methods with one or more parameters missing a type: 1
	1. class:isc.enable, ParamName=enable, type=

[Isomorphic]

These are generally attributes for internationalization, which would be set once ever, right after the framework is loaded and before any other application code runs. They are set via [targetClass].addClassProperties().

[kylemwhite]

General question: What is the proper way to set a Class API property that does not have a setter?

Example, I am trying to set the AMIndicator (and PMIndicator) property on the Time class. According to the docs, it is writable but there is no setter and there is no setProperty() method on the Time static class nor the Class static class. So, what is the proper way to set it?

[Isomorphic]

Looks like there was a merge problem and last night's build went out with some changes reverted, including the addition of getDataSource() docs. Already corrected for tomorrow's build.

[kylemwhite]

Did method:ListGrid.getDataSource get removed?

[kylemwhite]

VisualBuilder and SelectionOutline and all the others are on the list because in the Docs there is no 'extends Class' in the description as there is with most other classes that inherit directly from Class.



I have just noticed also that the description says 'for internal use only' so perhaps there shouldn't be any TypeScript representation at all. If so, could we put an attribute on those classes that are for internal use only so the generator will know to not generate anything for them?

For libraries of static methods: Yes, marked as object with staticMethods seems more appropriate and would help the generator do the right thing (i.e. it will know not to add 'extends Class').

For the extensions of native JavaScript objects: Could we mark them as something different? The reason being that they need to be handled differently than classes and objects. Classes and objects become interfaces with the same name in TypeScript (and also the _Static and _Props versions). For the extensions, so far I've only dealt with Array (manually) and it seems to be working (altough it is not complete) so I'm assuming Date and String will be similar. This code is near the top of the isc.index.d.ts file:

/**
 * Generic extensions to JavaScript Arrays. You can call these on any Array.
 * JavaScript's native Array is retrofitted to support the List API (not implemented yet).
 */
interface ArrayConstructor {

    isLoading(value: any): boolean;
    compareAscending(first: any, second: any): number;
    compareDescending(first: any, second: any): number;

} // Array

If there were some way to identify these, then the generator could automatically do the right thing (i.e outside of the Isc namespace and appends Constructor to the name) without maintaining a list of special cases.

[Isomorphic]

Regarding your list of possible non-classes:

VisualBuilder and SelectionOutline are indeed classes. Not sure why they're on this list.
"TooLStripSeparatorEditProxy" appeared in the doc wrongly due to a typo we'll fix.

"EBay" shouldn't be there at all, we'll get rid of it.

WSRequest, FacetValue and ServerObject should all actually be @object, we'll fix that.

These are libraries of static methods which cannot be true classes because they need to exist before the Class system itself loads, so cannot be true classes:
isc
FileLoader
History

These are extensions of native JavaScript objects:
Date
String

For both categories, we could alter these to be @object, and add a new type of definition like @staticMethod, the equivalent of @classMethod but for objects. Would that work?

[Isomorphic]

Just access the ID property on the DataSource returned by getDataSource().

[kylemwhite]

I see in today's build that the ListGrid.getDataSource() method has been documented. This broke my build (in a good way) because it told me that my own definition of getDataSource() was redundant and so I removed it, all good.

However, I've also been using the property .dataSource to retrieve the string ID of the DataSource. Since the generator is following the rules (i.e. not creating the property if a getter exists) there is no longer a .dataSource property. As a workaround, I've done the following:

(grid as any).dataSource

I think the issue stems from the fact that the .dataSource proprety can hold an object or an ID (or both?). Would it make sense to have a getDataSourceID() method as well?

[kylemwhite]

I hate to bring this up again but I'm still confused on the definition of Class vs. Object. Previously I understood that the difference was that a Class ultimately inherits from the base 'Class'. However, I've manually checked a bunch of classes that don't have an inheritsFrom attribute and found that they do not ultimately inherit from Class. So, if they don't inherit from Class, then why are the called classes? I.e. how are they different from Object? Examples:

• Date
• EBay
• FacetValue
• FileLoader
• History
• isc
• SelectionOutline
• ServerObject
• String
• Time
• TooLStripSeparatorEditProxy
• VisualBuilder
• WSRequest

This is not an exhaustive list, just the one's I happened to manually check through the docs and they are noted in the Errors.txt file.

[kylemwhite]

Yes, I noticed that a lot of them have been fixed, thanks. I'm looking at the latest file (http://www.smartclient.com/smartclie...erenceDocs.xml) and I don't see the inheritsFrom attribute on CanvasItem

 <docItem type="class" ref="class:CanvasItem" description="FormItem which renders a Canvas inline in a DynamicForm instance.&#010 <P>&#010 CanvasItem is ${isc.DocUtils.linkForRef('attr:CanvasItem.shouldSaveValue','shouldSaveValue')}:false by default, meaning that&#010 no value from the CanvasItem will be present in ${isc.DocUtils.linkForRef('method:DynamicForm.getValues')} and no value will be&#010 saved when ${isc.DocUtils.linkForRef('method:DynamicForm.saveData')} is called. This is appropriate if the Canvas does&#010 not participate in editing a value of the form and is embedded in the form for layout or UI&#010 purposes only (e.g. ${isc.DocUtils.linkForRef('class:ButtonItem')}, ${isc.DocUtils.linkForRef('class:SectionItem')}). Note that some built-in CanvasItem&#010 types override the shouldSaveValue default to true (e.g. ${isc.DocUtils.linkForRef('class:MultiComboBoxItem')}, ${isc.DocUtils.linkForRef('class:RichTextItem')}).&#010 <P>&#010 If you set ${isc.DocUtils.linkForRef('attr:FormItem.shouldSaveValue','shouldSaveValue')}:true, a &#010 ${isc.DocUtils.linkForRef('method:CanvasItem.showValue','showValue')} event will be raised to provide a value that your&#010 item should display. Handle this event by calling methods on the Canvas you've created&#010 to cause the value to be displayed.&#010 <P>&#010 The ${isc.DocUtils.linkForRef('method:CanvasItem.showValue','showValue')} event will be triggered in various situations where&#010 the form receives data, including a call to ${isc.DocUtils.linkForRef('method:DynamicForm.setValues')},&#010 ${isc.DocUtils.linkForRef('method:DynamicForm.editRecord')}, or if ${isc.DocUtils.linkForRef('method:DynamicForm.fetchData')} is called and a Record&#010 is returned. Bear in mind that the <code>showValue</code> event can be called when the form&#010 and your item have not yet been drawn; in this case, store the value for later display.&#010 <P>&#010 To provide a value to the form, call ${isc.DocUtils.linkForRef('method:CanvasItem.storeValue')} whenever the user changes&#010 the value in your Canvas. Generally, if storeValue() is called then&#010 ${isc.DocUtils.linkForRef('attr:CanvasItem.shouldSaveValue','shouldSaveValue')} should be overridden to true. Note that&#010 the form <b>will not</b> call getValue() in order to discover your item's value, so there is&#010 no purpose in overriding this method; instead, call storeValue() to proactively inform the&#010 form about changes to the value. This approach is necessary in order to enable change events.&#010 <P>&#010 If you cannot easily detect changes to values in your Canvas, a workaround is to call&#010 <code>storeValue</code> right before the form saves." name="CanvasItem">
   <attrs>attr:CanvasItem.height</attrs>
  <attrs>attr:CanvasItem.multiple</attrs>
  <attrs>attr:CanvasItem.shouldSaveValue</attrs>
  <attrs>attr:CanvasItem.canvas</attrs>
  <attrs>attr:CanvasItem.canvasConstructor</attrs>
  <attrs>attr:CanvasItem.canvasDefaults</attrs>
  <attrs>attr:CanvasItem.canvasProperties</attrs>
  <attrs>attr:CanvasItem.autoDestroy</attrs>
  <attrs>attr:CanvasItem.overflow</attrs>
  <attrs>attr:CanvasItem.minHeight</attrs>
  <attrs>attr:CanvasItem.maxHeight</attrs>
  <attrs>attr:CanvasItem.editCriteriaInInnerForm</attrs>
  <attrs>attr:CanvasItem.applyPromptToCanvas</attrs>
  <attrs>attr:CanvasItem.prompt</attrs>
  <treeLocation>Client Reference/Forms/Form Items</treeLocation>
  <methods>method:CanvasItem.storeValue</methods>
  <methods>method:CanvasItem.updateCanvasTabPosition</methods>
  <methods>method:CanvasItem.setCanvas</methods>
  <methods>method:CanvasItem.canEditChanged</methods>
  <methods>method:CanvasItem.readOnlyDisplayChanged</methods>
  <methods>method:CanvasItem.shouldDisableCanvas</methods>
  <methods>method:CanvasItem.isFocused</methods>
  <methods>method:CanvasItem.hasAdvancedCriteria</methods>
  <methods>method:CanvasItem.canEditCriterion</methods>
  <methods>method:CanvasItem.getCriterion</methods>
  <methods>method:CanvasItem.setCriterion</methods>
  <methods>method:CanvasItem.setPrompt</methods>
  <methods>method:CanvasItem.createCanvas</methods>
  <methods>method:CanvasItem.showValue</methods>
 
  </docItem>

[Isomorphic]

We've added explicit "inheritsFrom" markings for almost everything now (except, as discussed before, those that extend the base Class), and the last few should be done this week. One note on this: CanvasItem was listed as missing an inheritsFrom in your Errors.txt, but it in fact already had one, so that may be some kind of glitch in the script.

[kylemwhite]

Ok, I'll leave it as is... override away!

[Isomorphic]

It's valid to override these other methods, so long as the developer doesn't make assumptions about when and how the method will be called that aren't part of the documented guarantees. So we wouldn't want to either prevent this or warn in any way that the property doesn't exist or flag it as a custom property.

[kylemwhite]

Isomorphic: Currently, the ClassNameProps interfaces declare every method for the particular class (for overriding). This is probably not ideal as I'm sure there are many (most?) methods that should not be overridden. Is there any way the generator could determine which methods are appropriate to expose in the ClassNameProps interfaces? For example, when creating a new ListGrid, one certainly might want to override (implement) the cellClick() method so it should definitely be exposed in the ListGridProps class. However, it's probably not appropriate to expose the bringToFront() method as that's not really meant to be overridden (I don't think). A first attempt might be to expose only those that are marked as being in the events group but I'm not sure if that's completely accurate. Thoughts?