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

    MultiDS with Multilink TreeGrid


    I'm trying to get the TreeGrid (loadDataOnDemand = true) working with MultiDS and Multilink functionality. I am using SmartClient Version: v12.1p_2020-08-16/Enterprise Development Only (built 2020-08-16).

    I managed to get the MultiDS working. However when I try to use the multilink functionality (linkDataFetchMode "single") as well, things start to fall apart.

    I can get the first level of data displayed. However when I try to expand, it doesn't show the children.

    It seems that the problem lies in how getDrawArea() (ISC_Grids.js:5527) of the treegrid body determines the draw area in case of mulitlink.
    getDrawArea() calls getTotalRows() (ISC_Grids.js:58299), which calls (ISC_DataBinding.js 59380), which invokes Super (ISC_Core.js:40873). This calls _getCachedNodeLength(this.root), which in turn calls _getCachedNodeLengthFromIndex(node, path) (ISC_Core.js:36396). This returns entry.paths[path].nodeLength;

    Since it always checks against the nodeLength of the root node, it seems it will always just return the number of records directly under the root node.

    I had to modify the __add function of the ResultTree because it tried to _incrementRecursionCount, _decrementRecursionCount and _getRecustionCount failed without explicitely specifying the path. The _assert parent == root failed for nodes not in root.

    I'm not sure if I'm not populating the data correctly, or that the multilink is not working with loadDataOnDemand? Is there more in depth documentation on multilink trees?

    Attached Files

    The longest single doc on how multilink trees work is here and it's rather in depth.

    Unfortunately, you've shown us zero information about the data you're providing, and the long list of internal methods doesn't help. If you can show us runnable code, we can point out what's going wrong.


      Thanks, for your reply.

      I have managed to create an example for you. This recreats the assert error as mentioned in the first post.
      Attached Files
      Last edited by dw_qservices; 14 Apr 2021, 02:34.


        This modification to the __add function gets me passed the assert error in the previous post. This gets me to the length problem mentioned in the first post.
        Attached Files



          It seems after the forum maintenance, some posts have disappeared. Can you give me an update? Thanks!


            Just a note that a developer has been assigned to look at this test case. We will respond on this thread when we have investigated.

            Isomorphic Software Support



              Can I get an update on this? It has been over a month since the original question was posted. I understand this is complex and a solution has quite some impact on the existing code. More and more parts of our application start to depend on a solution for this problem. I'd like to know whether we can continue on this path and we can count on a solution, or that we need to find a workaround for this altogether? Any info would be nice.



                Sorry for the delay, but you have not purchased support from us, and you are asking us to look at and correct your code for you. We would like to do so, but questions and issues from customers with support come first. When a lot is going on, it could take a while before we can provide free support.


                  Thank you for your reply. I understand that customers who purchased support have priority.
                  However, as you can find in my original question I did not ask to correct my code. What I requested was a better understanding beyond what is publicly available on multilink and multids trees.
                  It is clear from the internal code that multids, while it is very much integrated in the regular tree functionality, was not finished, and will not work out of the box. It is also clear from the code that multids trees and multilink trees are not yet integrated and somewhat incompatible at the moment, which I have shown listing the steps of the internal code. If I have a better understanding of the thought process behind some of the internal code, I'll be able to create my own working solution.
                  My request for a better understanding of the internal workings was met with a request for an example what is going wrong, which I provided.
                  I'm ok with buying support, but if you are
                  unable to shed a single shred of light on the internal workings of this part within a month's time, I'm not confident that the way multids or multilink trees are implemented are even part of the active knowledge within your team. For all I know the original developers of these parts left your company without documentation and it is just legacy which you dare not touch, because it is way too integrated and things start to fall over as soon as you change something.



                    Sorry, we hadn't had a chance to look closely at your test case.

                    multiLink trees are a documented and supported feature with automated tests ensuring that the feature continues to work as documented.

                    multiDS are not a documented or supported feature.

                    The people who wrote the multiDS and multiLink features are our CTO and lead server-side developer respectively, and they are still very much with the company.

                    We will ask you politely that you please not post defamatory unsubstantiated speculation to our public forums when you are upset about the slowness of the free service received when asking about using undocumented features. The reason the team is busy is because we are working on a workaround for a bad Chrome regression so you never have to find out how the Chrome team messed up. In light of that, you came across as rude, to say the least.

                    Anyway, there are two paths forward for you:

                    1. use the DataSource facade pattern to unify record coming from multiple other DataSources, so you are no longer trying to use an undocumented, unsupported feature.

                    2. use Feature Sponsorship to make multiDS trees into an officially documented and supported feature. In sponsoring, you can specify that it has to work with multiLink trees if you like, then automated tests will be created for that specific scenario so the feature never regresses


                      I apologize for coming across as rude. But while I had no intention of being rude, you calling me such, is the pot calling the kettle black.

                      I can fully understand things taking long, and having other priorities, especially in the light of the recent incident affecting the company. Any answer shedding light on the situation would have acceptable.

                      What is not acceptable is you accusing me of wanting you to correct my code for free. I asked no such thing and do take offense for that.

                      I simply asked what the thought behind some internal pieces of code were. You could have simply answered something like: during the initialization of the multilink tree it is expecting such and such for this and this reason and raises an exception because it cannot continue for this and this reason. For the multids tree this is the moment in the code where these requirements can be fulfilled. The record count for rendering in a multilink tree is updated here and here, records from child datasources should be added somewhere in the code. These are simple answers which could be answered in a few minutes if there is active knowledge about the internal workings. I didn't even need an in depth answer or a working code sample, just a general idea of what is going on. Your inability to answer this simple question made me seriously doubt whether this active knowledge is even present, especially since multids trees are present, yet undocumented since at least Dec 2008 (Treegrid with nested (Rest)DataSources - SmartClient Forums). You and I both know that if code hasn't been touched for over 12 years, even if the original developers are still present, it might as well can be considered legacy code.

                      Since you asked me to provide a working example and told me a developer is looking at it, and since I hadn't gotten an update in a while, I simply asked whether I could continue building on the current code base and expect an answer which will get me have multids and multilink trees working together nicely or that I have to look at other solutions?
                      Instead of simply telling me, that the impact of getting multids and multilink trees working together is too big and the only path forward to get it working is to use Feature Sponsorship (which would have been a satisfying answer on itself, but baffles me that it would take over a month to come up with), you accuse me of wanting you to correct my code for free. Not only that, you try to sell me on purchasing support, which turns out would not even get me a solution.

                      If I come across as rude, it is because I am annoyed at you not being open with me and answering my questions, but instead start accusing me of asking things, I didn't ask for. When I was evaluating smartclient you did not answer my questions as well, because you assumed we would only use the Community edition. After explaining we were interested in getting the Enterprise version, you promised to do better. Based on this promise I gave my company the recommendation to get a license. Also, you did not even mention requiring to purchase support at the time.

                      I will discuss the options within the company. What I need to know from you is: what timelines can I expect if we sponsor this feature, what it would cost and if we would get continued support on this feature or need to purchase separate support?


                        Sorry about referring to this as "look at and correct your code". This happened because it appeared at first that you were simply struggling to use documented features and, at the triage phase, we didn't realize you were trying to use undocumented, unsupported features.

                        Normally this would have been recognized at the triage phase, but wasn't this time (too much going on!). One thing that would help is: if you are trying to use an undocumented, unsupported feature, say so explicitly. If we had realized you were trying to use an undocumented feature, you would have been given the options around Feature Sponsorship right away instead of this issue languishing a month, assigned to someone too busy to look at it.

                        Anyway, if you were simply trying to use multilink trees, which is documented, supported, and has a lot of automated tests ensuring it's still working, it would have been quite accurate and fair to say that you were asking for us to "look at and correct your code for you".

                        Also, please realize that when you say "you could have simply answered" you then go on to describe quite a bit of work! There are only so many hours in the day, and again, you don't have support, and even if you did, there is no possibility of having an extended discussion about an unsupported feature - support is priced on a flat fee basis, so discussion are limited to use of supported features. If you would like to have a (potentially unbounded) conversation about the inner workings of something you found while inspecting the code, that's available too, but of course it is billed as hourly consulting, not as a flat support fee.

                        We're sorry also that you didn't realize about the importance of support, but to be fair we really do emphasize it in lots of places on the website, in the FAQ, in the product documentation itself, etc. If there is some spot where you think an additional mention should be added, where you would definitely have seen it, please let us know!

                        Further, there is really no mystery about multiDS trees: it works for the limited purposes we have for it, and has never been promoted to a supported feature. If you are still caught in some kind of "crisis of confidence" about our staff, we would invite you to simply diff various recent versions of the source code: you can see extremely sophisticated work going on. Better yet, check out Reify, which will blow you away!

                        Finally, the way Feature Sponsorship works is that your feature is added to the next release (so 13.0 - but the timeline is a bit tight to get it in), however, for a small additional fee we can prepare a "patch" that adds the feature with the same APIs to an existing release. If you are in a hurry, the previously recommended DataSource Facade pattern is a simple way to use multiple DataSources in a tree (multilink or otherwise).