Announcement

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

  • kylemwhite
    replied
    I've just downloaded 11.1d and indeed the referenceDoc.xml file has (at least one) inheritsFrom attribute that didn't exist before.... looks promising. I am working on parsing the file (my old code didn't work, has the schema changed?) so I can generate the types and interfaces. I'll re-post when I've made some significant progress.

    I am much more proficient at C# than JavaScript or even TypeScript at this point so it probably makes sense for me to stick with that for the typedef generator. I think the referenceDocs will contain all the information I need once fixed up.

    Yes, there are other issues with the referenceDocs which could be improved... both for the typedef generator and for the SmartClient reference (IMHO). Many types (type and valueType attributes) are specified in the referenceDocs with an English description vs. an actual JavaScript type. For example integer, Integer, int, float, and Float are all things that we understand, but JavaScript (and TS) only knows number. The fact that the number should be an int or float should be in the description field but not the type field. Other examples include: Array of T and Array[] of T which should just be T[]. xxClassName should just be string (with the appropriate description of what that string should contain of course) etc. I'll probably have more as I progress. I don't know how easy it is for you to update the referenceDocs, which is why I mentioned the DB but parsing the referenceDocs is fine with me (once I generate the XSD and the proxy classes). Also, I'll need to parse out the link codes (${isc.DocUtils....}) into just text or maybe JSDoc link codes. If the raw data was available, that would make it easier than parsing out the codes (although I can't say I know what that would look like).
    Of course I can write custom rules to transform int to number etc. but it would be cleaner if the referenceDocs was consistent and we didn't have to do that.

    In the latest version I downloaded today, the SmartClient Reference page doesn't seem to be working. I can open the developer console but when I click the Reference Docs tab, it just gets stuck with a dialog saying "Loading Documentation modules". There is a JS error that says, "Uncaught TypeError: Cannot read property 'getCurrentHistoryId' of undefined. Tested in Chrome and IE... same thing. Hopefully that can be fixed soon as the Reference Docs greatly helps me with the typedef generator.

    Thanks for the support.

    Kyle

    Leave a comment:


  • Isomorphic
    replied
    Hi Kyle, thanks for stepping up to help with TypeScript. It's true that it's popularity is starting to rise.

    In the latest release of SmartClient (11.1), the inheritance chain is now explicitly listed in referenceDocs.xml (there may still be gaps - let us know), so that particular issue should be solved. Note that a possible approach is just to generate the TypeScript interface definitions in a browser-based application running SmartClient, which allows runtime information like the inheritance chain to be checked, and is part of why our own SmartClient Reference is a little more complete than referenceDocs.xml (aside from inheritance, it can look up things like default values on the fly).

    Is there any other information that you've noticed that's missing from referenceDocs.xml and that is needed for TypeScript generation?

    As far as targeting a different format than referencesDocs.xml, is there any particular format you have in mind?

    Leave a comment:


  • kylemwhite
    replied
    Isomorphic and all,

    Since nothing appeared on DefinitelyTyped, I decided to give this a go myself. I now see the issues that MrHighTech and others have run into. I.e. the referenceDocs.xml file is not completely accurate and missing things like inheritsFrom attributes. I have been able to manually code just the parts that I am using as I suspect a lot of others have, but this approach would not be appropriate for a project hosted on DefinitelyTyped or NuGet etc.

    Since isc is such a huge library, code generation is really the only practical way to produce a complete TypeScript type definition library and the referenceDocs.xml file has a perfectly good schema to include the correct types and interfaces including inheritance and documentation. I've actually generated a file (that compiles and works) of just the types but not the interfaces (classes) because of the missing inheritsFrom attribute issue. Even with the types, there are many inconsistencies which can be overcome with custom rules, although it would be nice if we didn't have to do that. To keep the library up-to-date, the generation would need to be automated, thus making complete and accurate source information even more important.

    With my generated types and manually-created interfaces, my TypeScript coding experience in Visual Studio is very pleasant and I've found and fixed tons of bugs. It's very similar to coding in Java with SmartGWT but I can now code everything in Visual Studio and not worry about using another IDE like Eclipse or NetBeans. I suspect this approach, combined with Isomorphic's sample of .NET and MVC, is very attractive to other .NET developers as well.

    I would be happy to continue the work to generate the rest of the isc TypeScript library and submit it to DefinitelyTyped if we can get a complete and accurate source for code generation so that the library can be made as robust as possible. The source could be a revised referenceDocs.xml file or whatever it is generated from (a database?) And I would be happy to contribute the necessary information to help improve the quality of the source.

    TypeScript is rapidly gaining in popularity (over-taking coffeescript), especially (I suspect) among .NET developers such as myself. It's adoption is no longer 'tepid' as previously stated in another post in 2013. I am willing to contribute to the community but need support from the source (and probably support from the community for tests, documentation etc.) Or, if Isomorphic wants to do it all, that would be even better.

    Thanks,

    Kyle
    Last edited by kylemwhite; 19 Apr 2017, 11:09.

    Leave a comment:


  • antanas.arvasevicius
    replied
    Hi, I'm also using TypeScript, but we've made interface declarations only for api which we are currently using in project. There is more problems as how to integrate TypeScript class system to SmartClient`s system.
    For Example if we'll need a subclass of ListGrid

    Code:
    class MyListGrid extends isc.ListGrid {
    }
    it won`t work.

    Maybe is it possible to call some internals of SmartClient to emulate initialization of dummy classes, e.g. we could have a isc.Component which will call isc.[component].create({}, THIS); and then SmartClient will attach all its behavior to that specific object by prototype, and we'll had an interface declaration of that specific class so all IDE autocompletion would work.

    pseudo code:

    Code:
    class Component {
       constructor(properties) {
    
          // TODO: needed new SmartClient API
          // Class.createOnGivenInstance(this, properties, a, b, c, d) 
          // which will create and initialize all methods on a given 
          // object instead of creating new. 
    
         window['isc'][this.componentClass()].createOnGivenInstance(this, properties);
    
    
       }
    }
    
    class ListGrid extends Component implements isc.IListGrid {
        // @override
        protect componentClass() { return 'ListGrid'; }
    }

    Leave a comment:


  • kylemwhite
    replied
    MrHighTech,

    How's your SmartClient TypeScript project progressing? I am now working on a project using SmartClient and (maybe) TypeScript. Having the SmartClient type definitions would sure be nice. If you've got a good start, maybe I can assist.

    Leave a comment:


  • MrHighTech
    replied
    Thanks for a quick reply!

    I will use the extends when it is available for now then. We'll see how things turn out. Keep you guys posted.

    Leave a comment:


  • Isomorphic
    replied
    Thanks for taking this on, we look forward to your results.

    Since the SmartClient Reference is actually a SmartClient application, it derives certain information directly from SmartClient at runtime rather than relying on the referenceDocs.xml file to contain it.

    However, this particular circumstance may be the sole one you actually run into when implementing TypeScript, and it probably doesn't matter anyway - we generally put in the @inheritsFrom tag in JSDoc if the inheritance chain is important. In the case of ListGrid inheriting from VLayout, really the only valid way to use the superclass functionality is via listGrid.gridComponents; direct calls to addMember() or removeMember() would be messing with internals.

    Leave a comment:


  • MrHighTech
    started a topic TypeScript integration

    TypeScript integration

    hello Isomorphic and all,

    I am currently playing with TypeScript and I actually see value with it. There are a couple of older posts here about using the referenceDocs(js/xml).

    I am working on that and will contribute it to DefinitelyTyped when it is completed. I think a first level integration should be available this week for testing, but it might take a bit more to have a nice integration with the create methods (Interfaces will help there).

    The reference docs are pretty good, but I am having a problem with inheritance. Looking at the documentation for ListGrid for example lists it as extending VLayout. But the field inheritsFrom is not present (only there in a couple of places).

    The implementsInterfaces are also present, but I haven't checked them thoroughly yet.

    I was under the impression the online documentation is generated form the referenceDocs... Any ideas on how to get a reliable hierarchy from the the file ?

    Thanks!
Working...
X