[kylemwhite]

OMG. Post #45 is soooo yesterday. Yes that list could have been old. The current list is updated daily in the repository here: https://github.com/kylemwhite/isc/bl...ter/Errors.txt. I've got everything automated to download the latest file at 7am (CA time) and generate the latest files. When I get into the office, I can check them out, compile and if everything is good, commit to the repository.

I've just now adjusted the generator to create the Errors.txt file BEFORE applying fixes and the count of missing inheritsFrom is up to 202. I know that most of these really implicitly inherit from Class but there are still many that do not (VLayout, HLayout etc.) and I don't have an automated way of distinguishing between the two cases. Suggestions are welcome.

[Isomorphic]

Layout is on the list in your post #45. So perhaps for that particular post you just copied from a stale list.

[kylemwhite]

Layout is not on the list. Do you have another example of one (or several) that has been recently added?

[Isomorphic]

In Java when you define a new Class you do not have to declare that you inheritFrom Object. Same thing with SmartClient, except our implicit base class is called "Class". So we don't want to go add dozens of redundant definitions throughout our codebase, just as someone writing in Java would not want to add them. And if were just automatically added to all classes that lacked it, that would have the same effect as if the script just assumed it, so no point.

That file is up to date, yes, and we've checked that it does have additional inheritsFrom, such as an Layout. So your list appears stale.

[kylemwhite]

Because we are adding the inheritsFrom attributes (and a few in that list already have it by the way, it must be stale).

I've been regenerating every day from this URL: http://www.smartclient.com/smartclie...erenceDocs.xml and I haven't seen any additional inheritsFrom attributes. Am I using the correct file?

[kylemwhite]

@jaredm: Thanks for the encouragement. Please have a look at the repository https://github.com/kylemwhite/isc and provide feedback. If there are particular classes, objects or methods you need that are missing, let me know and I'll include them in the next release (if they generate properly).

[kylemwhite]

I've really been trying to grasp why we have differing opionions on the inheritsFrom attribute and here's what I've concluded. I've had a different model in my head than what Isomorphic does. For items marked with type="class":

My (working) definition of the inheritsFrom attribute

A class inherits from whatever is in the inheritsFrom attribute which ultimately inherits from Class. If there is no inheritsFrom attribute, then it must be the base Class (or a mistake).

The (presumed) Isomorphic definition:

All classes inherit directly from Class (except the base Class) unless the inheritsFrom attribute specifies otherwise, in which case it inherits from the inheritsFrom class which ultimately inherits from Class.

I can see now why (using the Isomorphic definition), marking classes with inheritsFrom="Class" would seem redundant. Since they're marked with type="class", it is implied that they inherit from Class already.

These definitions are really close. However, I prefer my definition (all classes have an inheritsFrom attribute unless it is the base class) because it makes it easier for code generators to know what to do. If a class is missing an inheritsFrom attribute, it is very easy to discover and thus fix. And, if it seems redundant, who cares? It doesn't make the file significantly bigger but it DOES make things clearer, more robust and easier to find mistakes via automation. A bit of redundancy is a small price to pay for that.

With the (presumed) Isomorphic definition, if a class is missing the inheritsFrom attribute, there's no way to know if that was on purpose because it inherits directly from Class or if it is a mistake (without looking outside of the referenceDocs.xml file).

I can see no downside to using my definition, I doubt that it would break the exisitng SmartGWT or Docs code generators because nothing will change in the framework itself and they would (probably) generate the proper 'extends' based on the attribute instead of inferring it from the lack of the attribute. I'm just proposing a modification to the referenceDocs.xml file (by including an inheritsFrom attribte in ALL classes except Class) to make is easier for all code generation and make it more error-proof. This definition is also consistent with objects because:

Yes, objects with inheritsFrom attributes inherit from whatever is declared. Others do not.

(i.e. there is no implied inheritsFrom)

Please consider. Thanks.

Also, neither of our definitions work for the isc class as it does not inherit from Class at all. It seems to me that it should be marked as type="object" (and it is actually referred to as 'The isc object' in the docs).

[Isomorphic]

For the other 190, how can the generator tell if they are supposed to inherit from Class or if they are just missing a legit inheritsFrom attribute?

Because we are adding the inheritsFrom attributes (and a few in that list already have it by the way, it must be stale).

There are 8 objects with inheritFrom attributes:

Yes, objects with inheritsFrom attributes inherit from whatever is declared. Others do not.

[kylemwhite]

If it's type="class" it inherits from Class if nothing else is specified.

Unless, of course, it is Class or isc. If the classes specified inheritsFrom='Class', then they would be easily distinguished from classes that are just missing the attribute such as:

• Layout
• VLayout
• HLayout
• ToolStripButton
• SectionStack
• ToolStrip
• RestDataSource
• HTMLPane
• Menu
• etc.

I've found 192 classes (not objects) that don't have an inheritsFrom attribute. Ok, I know that Class and isc don't inherit from anything, those are special because they are absolutely base classes. For the other 190, how can the generator tell if they are supposed to inherit from Class or if they are just missing a legit inheritsFrom attribute?

If it's type="object" it doesn't inherit from anything

Well, according to the file, that's not true. There are 8 objects with inheritFrom attributes:

1. AdvancedCriteria inheritsFrom Criterion
2. EditNode inheritsFrom PaletteNode
3. LinearGradient inheritsFrom Gradient
4. ListGridRecord inheritsFrom Record
5. MenuItem inheritsFrom ListGridRecord
6. NavItem inheritsFrom TreeNode
7. RadialGradient inheritsFrom Gradient
8. SimpleGradient inheritsFrom Gradient

or.... are they supposed to be classes?

[Isomorphic]

Actually, on #6, here's how to handle it:

1. if there are quotes, that's the literal string value
2. if there aren't, it's a reference to another property, eg TableView.NAVICON_ONLY means go look up the class attribute NAVICON_ONLY on TableView, and use that attribute's value. That particular attribute was missing from the docs, but we're adding it, and also doing a review of any others that might be missing that are referred to by type declarations.

[Isomorphic]

1. Re: ListGrid.selection
Can it be defined as Selection | CellSelection? Sounds like that would be more accurate and compatible with TypeScript.

Sure, we can do this.

3. Re: isc.addProperties
Understood that it can take multiple arguments and the generator can handle that. My point was that the usual way that is described is by putting arguments 0-N in the name field, but in this one case, it's in the type field and the name field contains a single bracket. I'm assuming this is a typo.

Ah OK, we thought you meant that functions with N arguments couldn't be handled in general. Since they can, we've just corrected the typo that made this parse incorrectly. So it should now say "arguments 1-N" in analogy with other such methods (in tomorrow's builds).

4. Re: SectionStackSection.addItem()
Well that makes sense then as my first experience with SmartClient was really SmartGWT and I probably copied some code into my current JavaScript (now TypeScript) project. Why not spread the love and let us JS/TS people see it too? Sometimes you want to add something to a SectionStackSection after it's already been initialized. We can do that, right?

It's just a plain JavaScript Object, so we don't have a way to place methods on those. This is different in SmartGWT, where even plain JavaScript Objects like this end up with Java classes wrapping them. Note that the SmartClient way to add an item after init is sectionStack.addItem().

5. Re: Classes missing inheritsFrom
If they inherit from Class, then why not specify that? I don't see how it's redundant if it's not specified anywhere else (or is it?) I could assume that any class without an inheritsFrom attribute really inherits from Class except that...
If they are just objects, then can you change the type field to object (type="object" instead of type="class")? I need some way to know if an entity is supposed to inherit from Class or not.

If it's type="class" it inherits from Class if nothing else is specified. If it's type="object" it doesn't inherit from anything (or, if it's what TypeScript wants, you can say that it inherits from the native JavaScript Object).

6. Re: "Should string type values have quotes or not?"
This is probably best explained with an example. Some string-type values (or string enums or whatever) are defined like this:

<docItem ref="type:ControlName" type="type" description="..." name="ControlName">
<values value=""boldSelection"" description="A button to make the current selection bold."/>
<values value=""italicSelection"" description="A button to make the current selection italic."/>

(note the double double quotes around the value) and some like this:

<docItem ref="type:PointShape" type="type" description="Supported data point shapes for ${isc.DocUtils.linkForRef('attr:FacetChart.pointShapes')} are:" name="PointShape">
<values value="Oval"></values>
<values value="Square"></values>

I think the second type correlates to the Values with a period most of the time (but not in the example above).

Thanks for the example, we'll look into what's causing this.

[jaredm]

kylemwhite thank you for taking this on. I just came across it and am really looking forward to using it (we use TypeScript for other stuff, for some reason no one thought to apply it to SmartClient)!

[kylemwhite]

I see how the KeyIdentifier thing came up. It's from this piece of the file

 <docItem defaultValue="null" type="attr" definingClass="object:MenuItem" ref="attr:MenuItem.keys" 
valueType="KeyIdentifier | Array of [B]KeyIdentifer[/B]" description="Shortcut key(s) to fire the menu item action. Each key can be defined as a ${isc.DocUtils.linkForRef('object:KeyIdentifier')}.&#010 To apply multiple shortcut keys to this item, set this property to an array of such key&#010 identifiers." flags="IR" name="keys">
   <groups>menuKeys</groups>
 
  </docItem>

Notice in the valueType, it is misspelled in Array of KeyIdentifer (missing an i).

[kylemwhite]

1. Re: ListGrid.selection
Can it be defined as Selection | CellSelection? Sounds like that would be more accurate and compatible with TypeScript.

2. Re: ToolStripButton
Ok, nothing for me to do here. The xml file says Button which correct most of the time.

3. Re: isc.addProperties
Understood that it can take multiple arguments and the generator can handle that. My point was that the usual way that is described is by putting arguments 0-N in the name field, but in this one case, it's in the type field and the name field contains a single bracket. I'm assuming this is a typo.

4. Re: SectionStackSection.addItem()
Well that makes sense then as my first experience with SmartClient was really SmartGWT and I probably copied some code into my current JavaScript (now TypeScript) project. Why not spread the love and let us JS/TS people see it too? Sometimes you want to add something to a SectionStackSection after it's already been initialized. We can do that, right?

5. Re: Classes missing inheritsFrom
If they inherit from Class, then why not specify that? I don't see how it's redundant if it's not specified anywhere else (or is it?) I could assume that any class without an inheritsFrom attribute really inherits from Class except that...
If they are just objects, then can you change the type field to object (type="object" instead of type="class")? I need some way to know if an entity is supposed to inherit from Class or not.

6. Re: "Should string type values have quotes or not?"
This is probably best explained with an example. Some string-type values (or string enums or whatever) are defined like this:

<docItem ref="type:ControlName" type="type" description="..." name="ControlName">
<values value=""boldSelection"" description="A button to make the current selection bold."/>
<values value=""italicSelection"" description="A button to make the current selection italic."/>

(note the double double quotes around the value) and some like this:

<docItem ref="type:PointShape" type="type" description="Supported data point shapes for ${isc.DocUtils.linkForRef('attr:FacetChart.pointShapes')} are:" name="PointShape">
<values value="Oval"></values>
<values value="Square"></values>

I think the second type correlates to the Values with a period most of the time (but not in the example above).

7. Re: KeyIdentifier
Well wattya know?, it IS an object. I'll have that generated on the next round.

[Isomorphic]

Also from Errors.txt: KeyIdentifier has a declaration as an Object with properties, so it shouldn't be in your list of suspected string types. But we'll take care of the rest of these.