Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

  • kylemwhite
    replied
    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).

    Leave a comment:


  • Isomorphic
    replied
    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:


  • kylemwhite
    replied
    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
    For the one that have a lot of occurrences like URL, I would suggest to just make it a type with a baseType='string'

    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:


  • Isomorphic
    replied
    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:


  • kylemwhite
    replied
    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:


  • Isomorphic
    replied
    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:


  • kylemwhite
    replied
    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:


  • Isomorphic
    replied
    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:


  • Isomorphic
    replied
    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:


  • kylemwhite
    replied
    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:


  • Isomorphic
    replied
    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:


  • kylemwhite
    replied
    Are these supposed to be blank?:
    • ref="classAttr:StatefulCanvas.STATE_UP"
    • ref="classAttr:StatefulCanvas.UNSELECTED"

    Leave a comment:


  • kylemwhite
    replied
    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?

    Leave a comment:


  • Isomorphic
    replied
    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:


  • kylemwhite
    replied
    WOAH!!!!

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

    Leave a comment:

Working...
X