I just wondered whether Expand/Collapse functionality is still working (or intended to work) in the 1.2 version of ActiveForms when having more than one row dimension. I just checked the corresponding sample page (http://canvasserver:8080/samples/#/sample/component/activeform) and had in mind that in earlier versions I could expand the “Total Europe” node in the 2nd dimension. This seems no longer possible. I found the same behaviour after creating a new page based on a CubeView with two dimensions in the rows - I cannot expand in the second dimension.
In v1.2, we made some changes into the Active Form in order to make it even faster. The new Active form brings everything in one go. When you drill down or up on a consolidation, the Active Form now hide/show the rows instead of requesting the data into TM1.
The new active form now, depends on the subset element pass on to it. If the leaf elements of a dimension are not part of the subset or mdx defined in the tm1-ui-rpt-row, you won’t be able to drill down to these elements.
For example, in the samples application, the Region on rows are driven by the mdx {[Region].[1]} there is only one element Total Europe available:
Hi Vincent - I’m a little concerned about this statement. Are you saying that independently of the defined MDX or subset given as the active form rowset that Canvas will get the immediate children of any C elements not already drilled?? For large dimensions or even not so large dimensions with consolidations with lots of children (“lots” = 100s to 1000s) then this could have very bad performance consequences.
Sorry if it was confusing. Canvas does not bring all the dimension, it brings only what is defined in the MDX or subsets.
What I mean is that the Active form in Canvas v1.2 will bring all the data in one go (the first time the page opens or refreshes) depending on what is defined in the tm1-ui-rpt-config.**
Before Canvas v1.2 or in TM1 Active Form, when you drill down, the Active Form will request the data to TM1 and then display the rows so it will take a bit of time to get the data.
To make it faster, in Canvas v1.2, when you drill down or up, Canvas only shows or hides the available rows. If a row is not available in the page you won’t be able to drill down.
When you drill down, if the children are not part of the mdx or subset defined in tm1-ui-rpt-row, you won’t be able to drill down.
For examples in the Active Form of the samples application, the rows for the Region are defined by the following mdx: tm1-mdx="{[Region].[1]}"
When you open the page, Canvas brings only the “1” element which is Total Europe. Only Total Europe is available, you won’t be able to drill-down to the children.
To be able to drilldown, you need to update the mdx to show all children and then collapse the consolidations:
thanks for explanation (referring to my initial question). This also solves one of the issues we always had with TM1Websheets ActiveForms: we wanted to prevent users to further expand elements on purpose, which was not supported. This was especially annoying if you display elements in a different order than “hierarchycal”.
Conerning cw-ch’s doubts on getting the whole data in one go (instead of on-expand), I had a similar impression that this might result in a long load time if we want to offer a large dimension for full drill-down. I think we just have to try out whether we really have an issue or not. So far I’m happy with new ActiveForm 1.2 as for small to mid-size views, it is way faster.
Of course, it would be great to have kind of a mixture between old and new ActiveForm behaviour. E.g. we get everything in one go down to a specified expand level, and everything below on demand. That way, the developer could control the amount of data being retrieved on initial load and postpone the rest for expand actions. May be some future release of Canvas might bring this feature.
Hi Vincent - thanks for the explanation! This is really important to know at this is quite different from how websheet/excel active form and cube viewer work where consolidated elements by default can always be drilled down on. The new behaviour in Canvas while good on one hand in addressing requirements to define drill-down path and prohibit drill on element if not explicitly defined also has negative aspects like loss of flexibility for users and requirement to predefine for the report builder (what about rapidly changing dimensions or source system built dimensions where the structure might be unknown or subject to change?)
I agree with Andreas that “best of both worlds” might be needed.
sorry to bring up this topic again, but I now ran into the situation I outlined in my previous answer: I want to (actually I have to) provide a large (~86k elements) dimension hierarchy in the rows. On top level, this dimension only has a few elements, and this is the starting subset for the user. Now the user may drill down up to 6 levels until N elements. The thing is, I cannot predict where the user will drill down, so my only chance is to specify the whole drilled down dimension as tm1-ui-rpt-row. As you might imagine, this takes forever…
In fact, old active form approach worked better here, as the user would have to wait a short moment on each drill, but that was acceptable. At least the initial page was rendered quite fast.
Is there any recommendation on how to approach such a scenario? As outlined in previous post, here it would be perfect if I could preload the first 3 levels expanded, and then fetch the remaining drills on demand, each leading to a small delay on expand.
Having such a huge dimension is already challenging enough, but TM1 itself can handle the volume perfectly. TM1Web is currently implemented and shall be replaced by a more user friendly Canvas page - but I do not have a good plan to work around new active form behaviour.
As a workaround, I think I will offer the dimension elements as hyperlinks, which will set the clicked element as new entry point for the active form, again drilling down three levels from the new entry point. That way, the user will click 2-3 times until being able to reach the N level.
For this scenario I would recommend avoiding the Active-Form and instead implement the logic with a combination of ng-if’s and DBS’s or alternatively use the $tm1 service to dynamically load the children of the consolidated element as the user clicks.
This will give you a lot more flexibility and allow you to optimise it to work best for your scenario.
