I'm sure many of them are unnecessary now but it's a pain to go test each thing every time there's an update so if the generator still works, I don't mess with it. At some point I will clean it up. Just showing, in general, the complexities that I've dealt with so far, some of which I am still dealing with. In general, the stuff I'd like you to go over is the stuff that I manage to get into the Errors.txt file. And by looking at the Progress page, I can see that many have gone down to 0, which is great.
As long as we're making progress though, it's all good. There are actually more things that could improve the docs but they're more nit-picky and I'm saving them until after the big stuff is fixed (inconsistent casing for example).
Announcement
Collapse
No announcement yet.
X
-
We're double-checking on URL, URI and HTML. All of those were intended to receive baseType markers. The other two are typos and we'll get those too.
It looks like almost all of the "hardcoding" predates the many, many fixes we've announced in this thread. Do you need us to go back over those, or did you just not get around to updating after each fix?
Leave a comment:
-
The Errors.txt file is generated every day (assuming everything works). The current list of string types without a baseType is listed here:
Code:Attributes suspected as string types but do not have the baseType set: 47. === URL:32 === 1. attr:ActiveXControl.codeBase, valueType=URL 2. attr:Canvas.appImgDir, valueType=URL 3. attr:DataSource.dataURL, valueType=URL 4. attr:DateChooser.nextMonthIcon, valueType=URL 5. attr:DateChooser.nextMonthIconRTL, valueType=URL 6. attr:DateChooser.nextYearIcon, valueType=URL 7. attr:DateChooser.nextYearIconRTL, valueType=URL 8. attr:DateChooser.prevMonthIcon, valueType=URL 9. attr:DateChooser.prevMonthIconRTL, valueType=URL 10. attr:DateChooser.prevYearIcon, valueType=URL 11. attr:DateChooser.prevYearIconRTL, valueType=URL 12. attr:DrawImage.src, valueType=URL 13. attr:DynamicForm.action, valueType=URL 14. attr:DynamicForm.validationURL, valueType=URL 15. attr:Flashlet.codeBase, valueType=URL 16. attr:Flashlet.pluginsPage, valueType=URL 17. attr:Flashlet.src, valueType=URL 18. attr:FusionChart.chartsBaseURL, valueType=URL 19. attr:FusionChart.chartURL, valueType=URL 20. attr:HTMLFlow.contentsURL, valueType=URL 21. attr:ImgProperties.imgDir, valueType=URL 22. attr:ImgProperties.src, valueType=URL 23. attr:ImgTab.labelSkinImgDir, valueType=URL 24. attr:ImgTab.skinImgDir, valueType=URL 25. attr:ListGrid.headerMenuButtonIcon, valueType=URL 26. attr:Mail.templateFile, valueType=URL 27. attr:OperationBinding.dataURL, valueType=URL 28. attr:RPCRequest.actionURL, valueType=URL 29. attr:StretchImgButton.labelSkinImgDir, valueType=URL 30. attr:SVG.pluginsPage, valueType=URL 31. attr:SVG.src, valueType=URL 32. attr:ViewLoader.viewURL, valueType=URL === DOMElement:2 === 1. attr:Canvas.htmlElement, valueType=DOMElement 2. attr:DOMGrid.rootElement, valueType=DOMElement === CSSStyle:1 === 1. attr:Dialog.messageStyle, valueType=CSSStyle === URI:2 === 1. attr:SchemaSet.schemaNamespace, valueType=URI 2. attr:WebService.serviceNamespace, valueType=URI === HTML:7 === 1. attr:GroupNode.groupTitle, valueType=HTML 2. attr:Hilite.htmlAfter, valueType=HTML 3. attr:Hilite.htmlBefore, valueType=HTML 4. attr:Hilite.replacementValue, valueType=HTML 5. attr:ListGridRecord.singleCellValue, valueType=HTML 6. attr:MenuItem.title, valueType=HTML 7. attr:TreeNode.title, valueType=HTML === Field:2 === 1. attr:FormulaBuilder.field, valueType=Field 2. attr:SummaryBuilder.field, valueType=Field === FormItemClassname:1 === 1. attr:Operator.editorType, valueType=FormItemClassname
Here's a section of my C# code that I maintain to deal with inconsistent types. I know that some of them may be fixed by now but this illustrates the issues I've found. With these lists, it mostly all works. The next guy to try code generation will end up making similar lists (minus the ones that are fixed of course).
Code:// To fix missing inheritsFrom attributes Dictionary<string, string> dicInherits = new Dictionary<string, string>() { { "Layout", "Canvas"} , { "VLayout", "Layout"} , { "HLayout", "Layout" } , { "PortalLayout", "Layout" } , { "ToolStripButton", "Button" } // Or is is stretchImgButton? Documentation is conflicted. , { "SectionStack", "VLayout" } , { "BaseWidget", "Class" } , { "ToolStrip", "Layout" } , { "RestDataSource", "DataSource" } , { "HTMLPane", "HTMLFlow" } , { "DataSource", "Class" } , { "Menu", "ListGrid" } , { "ResultSet", "Class" } , { "ImgButton", "Img" } , { "Portlet", "Window" } , { "Time", "Class" } , { "RPCRequest", "Class" } , { "FormItem", "Class" } , { "MathFunction", "Class" } }; // These are all really just a JavaScript number string[] numberTypes = { "Number", "PositiveInteger", "Integer", "Float", "double", "int" }; // Thease are all really just a JavaScript boolean string[] boolTypes = { "Boolean", "bool" }; // Don't know how to deal with these so just make them any for now string[] anyTypes = { "Transaction Object" , "Object<String,SummaryFunction>" , "Object" , "object" , "Any" , "rect" , "measure" , "map" , "discovertreesettings" , "stringmethod" , "map<string,string>" , "RecordList" , "record properties" , "record" , "function" , "PrimaryKeys" , "subClass" , "Widget" , "Widgets" , "arguments" , "objects" , "button object" , "button widget" , "DataSourceRecord" , "DataSourceRecords" , "PKValue" , "varies" , "TimerEvent" // , "Callback" }; // These are all really Callbacks string[] callbackTypes = { "rpccallback", "AnimationCallback", "PrintCanvasCallback", "DataURLCallback", "ClientOnlyDataSourceCallback", "CollapseSectionCallback", "ExpandSectionCallback", "GetFileVersionCallback", "HasFileCallback", "HideSectionCallback" , "PaletteNodeCallback", "ShowSectionCallback", "ValidationStatusCallback", "GetFileCallback", "MessagingCallback", "ProcessCallback", "LoadScreenCallback" , "RPCQueueCallback", "CanPlayCallback", "PlaybackCompleteCallback", "CanPlayCallback", "PlaybackCompleteCallback", "TabIndexUpDatedCallback","ShiftFocusCallback" , "ExportImageCallback" }; // These are extra words that don't really refer to a type. They will be removed. string[] nonTypes = { "Multiautochild", "Autochild", "instance" }; //, "| subClass" }; // Infrequent types that would be difficult to fit in a general rule private Dictionary<string, string> weirdTypes = new Dictionary<string, string>() { {"Array of Array of int", "Array<Array<number>>" } , {"Map<Prefix,URI>", "Map<string, string>" } , {"Response", "RPCResponse | DSResponse" } , {"Request", "RPCRequest | DSRequest" } }; // These are things marked as Classes but do not inherit from Class. string[] notClass = { "isc" , "Date" , "Browser" , "Callbacks" , "WSRequest" , "ServerObject" , "History" , "String" , "TooLStripSeparatorEditProxy" , "SelectionOutline" , "VisualBuilder" , "EBay" , "FileLoader" , "FacetValue" }; // Not working for the reason listed Dictionary<string, string> excludedClasses = new Dictionary<string, string> { { "BooleanItem", "Extends CycleItem but CycleItem is not defined." } , { "ComboBoxItem", "Interface 'ComboBoxItem' incorrectly extends interface 'TextItem'. Types of property 'canEditCriterion' are incompatible." } , {"MultiComboBoxItem" , "Cannot find name 'ComboBoxItem'" } // , {"MathFunction" , "" } , { "MultiFileItem" , "Extends RelationItem but RelationItem is not defined" } , { "PickListMenu" , "Extends ScrollingMenu but ScrollingMenu is not defined" } , { "RelativeDateItem" , "Interface 'RelativeDateItem' incorrectly extends interface 'CanvasItem'. Types of property 'valueField' are incompatible." } , { "RichTextItem" , "Interface 'RichTextItem' incorrectly extends interface 'CanvasItem'. Types of property 'colSpan' are incompatible." } , { "ToolbarItem" , "Interface 'ToolbarItem' incorrectly extends interface 'CanvasItem'. Types of property 'colSpan' are incompatible." } }; // Really just strings, hopefully they'll be putting in baseType='string' so we won't need this list anymore. string[] stringTypes = { "ListGridGroupState" , "RelativeDateString" , "CSSClass" , "CSSText" , "CSSColor" , "CSSClassName" , "CSSStyleName" , "Color" , "SCClassName" , "SCImgURL" , "DataPath" , "DateInputFormat" , "ListGridFieldState" , "ListGridSelectionState" , "ListGridSelectedState" , "ListGridSortState" , "ListGridViewState" , "TreeGridOpenState" , "TreeGridViewState" , "FormItemBaseStyle" , "VelocityExpression" , "XPathExpression" , "HTMLString" , "DetailViewerViewState" , "FormatString" , "character" , "AutoTestLocator" , "ListGridViewState" // , "identifier" , "align" , "stringMethod" , "String" , "global ID" , "HTML Element" // Check this BEFORE HTML , "HTML" , "ElementName" , "XPath" , "URI" , "Prefix" , "Type" , "string Expression" , "String Expression" , "keyChar" , "animateShowEffectId" , "DOMElement", "DOM Element" , "datasource id", "URL", "id", "fieldNames", "fieldName", "Field", "Fields", "facetId", "facetIds", "facetValueGroupId" , "class object" /*, "KeyIdentifier", "keyidentifier",*/, "keyidentifer", "DSField" , "identifier", "string", "operationid", "formlayouttype", "domelement", "itemName" , "color", "urn", "valign", "classname", "cssclass" ,"CSSStyle", "name", "DataURLFormat", "FormItemClassname"}; // Skip these because they cause weird problems (redefined in subclasses?) string[] excludedAttributes = { "valuesManager", "ValuesManager", "dataProperties", "State", "dataGradients", "activeAreaHTML"};
Leave a comment:
-
Any system, doc viewer or code generator etc, can trivially look up the root type. We don't think it makes sense to add extra information to an already large file to obviate a trivial lookup. Let's stop kicking that dead horse..
Not sure what that other complexity is that you're referring to. The information we've added over various enhancements should have allowed you to eliminate hardcoded lists of string or numeric types, classes missing inheritance information, etc. We eliminated all such extra information from our processes for generating SGWT APIs.
Leave a comment:
-
Currently, the fail-safe is any as that works in TypeScipt. When I said it would greatly simplify gode-generation, I was referring to not only the current issue, but also to all of the other special stuff (lists of string types, number types, Callback types etc.) that I've already put in place that would have been unnecessary if a rootType attribute existed and for FUTURE code generation if that ever happens for a new language or something. Yes, I've taken care of most of it now and will implement the iterator to handle inherited baseTypes. I'm just suggesting that a rootType would have been, and could be in the future, very useful. Also, for the user-readable documentation, I would like to see something that says it is really just a string, rather than click through a bunch of links just to find out that it's a string. A rootType attribute would be perfect for this.
Leave a comment:
-
The baseType is now also displayed by the SmartClient Reference and allows better type guessing in our Visual Tools. It is not just for code generation.
You started out saying a root type would "greatly simplify code generation" but went on to say you could "easily add code to .. find the atomic type". Well, we agree with the latter assessment. This requires just a trivial helper method with a simple iteration inside of it.
Note, although there are no breaks in the baseType inheritance chain and our tools would catch it if there were, we would recommend falling back to type "string" if something goes wrong in baseType lookup.
Leave a comment:
-
I suspect that adding an attribute that specifies the root JavaScript type is also trivial to implement (whether string, number, boolean etc.), would greatly simplify code generation, and would also be useful in the documentation (I've wanted it since way before the TypeScript project). AFAIK, the whole concept of the baseType was introduced in this thread so I assumed that it was meant for code generation. I didn't realize it was being used for anything else, but you're right, I can easily add code to traverse the inheritance chain and find the atomic type, assuming there are no missing links in the chain, misspellings or other issues like we've seen in the inheritsFrom attribute.
Leave a comment:
-
2 above: the information in refDocs.xml is used for several purposes, not just code generators. We don't want to hide this information about inheriting types, and the lookup to find the base type is too trivial to implement for us to consider adding some kind of shortcut.
Leave a comment:
-
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
Leave a comment:
-
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.
Leave a comment:
-
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.
Leave a comment:
-
Are these supposed to be blank?:- ref="classAttr:StatefulCanvas.STATE_UP"
- ref="classAttr:StatefulCanvas.UNSELECTED"
Leave a comment:
-
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:- KeyName - Strings to identify the various keys on the keyboard.
- RelativeDateShortcut - A RelativeDateShortcut is a special string ...
- AutoTestLocator - An autoTestLocator is an xpath-like string ....
Leave a comment:
-
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.
Leave a comment:
-
WOAH!!!!
Yes, I noticed. typescript="true". String constants are all defined. Please let me know the plan. Thanks.
Leave a comment:
Leave a comment: