ThingWorx 9.7.1-b346
I have a mashup which is to contain multiple collections that will contain multiple cells each. The number of cells will depend on the user selected input parameters at run time; anywhere from 3 cells up to 12 is the most (I believe). Each of the collection widgets are using the same child mashup and will use the same configuration however will use data from different sources.
My collections will be in a table format with each cell forming a row the full width of the container. My child mashup and the collection settings are such that each cell needs to be 100px tall, any shorter causes visibility issues for parts of the cell/child mashup.
I need all collection cell rows to be visible at once, not hidden outside of the limits of a container requiring the user to scroll down in the collection container. With multiple collection cells having independent scrolls this can become a significant issue. I have not been able to have all cells visible without scrolling the container or setting a fixed container height large enough to accommodate the maximum of cells however this leads to empty space when less cells are needed. I have the same results with a single collection or multiple collections.
To attempt to resolve the issues I have experimented with Grow ratio and size range settings for the collection containers with little success. A high grow ratio gets close to expanding the container adequately but even at an extreme grow value my largest sets of collection cells will not be fully shown and requires a scroll. Additionally, I'm unable to scroll the page/parent container as a whole so even when I can push the grow ratio far enough to show a full set of collection cells I can not scroll any further down the page to view the next collection or any other elements in my mashup.
I have also tried using the Size Range settings for the collection containers; setting them at 300-1200px (My collections should always be 3-12 cells for any set of inputs). I have tested this combined with various grow ratio settings with seemingly no effect. Choosing the size range setting for container size does enable the vertical scroll dropdown to be set to "Disabled" however this setting does not appear to be respected as I am still seeing a scroll bar on the container with any configuration.
The only workable solution I have found is to simply set the collection containers to a fixed size matching the height of the maximum number of cells that may be contained (max 12 cells * 100px cell height = 1200px fixed container height). This works and looks great with a full 12 cells displayed however when fewer cells are needed there is just extra empty space in the container. Whether the collection is set to be centered, top or bottom oriented this leads to a poor appearance and an unfamiliar user may over look parts of the form, not realizing they must scroll past several cells worth of empty space.
Is there some other option to dynamically resize the container to always display all collection cells without scrolling?
Would it possible to achieve my desired results using a contained mashup instead? It would need to dynamically show the correct number of contained mashup widgets for each row of the data currently used in the collections.
Final idea, Is it possible to bind a value to the container fixed size value? As I know my cells always need to be 100px tall I could calculate the height needed for each collection and bind that value to the containers fixed height parameter. As far as visible in the UI it does not appear that container size parameters are bindable.
I appreciate any advice or discussion on this topic.
Thank you for reading. Have a good weekend.
Solved! Go to Solution.
Yes, I suggest you add the "Submit" button to that cell mashup.
In that cell mashup you can control the visibility of the widgets (or even their container) and the button via a couple of validators, which act on some "type" cell parameter. In your server-side code just do result.AddRow({ type: 'last' }); at the end of your service, and off you go. It is rather ugly implementation-wise, but quite easy to achieve.
You might need to figure out how to pass the Clicked event from the cell to the containing mashup, but there are several ways to achieve it, e.g. via setting a dummy session variable. Again -- not elegant, but will get the job done.
Hello @CC_13244540 ,
I am not sure you have a lot of options.
You have a Display which will be displaying multiple collections. Each Collection will be 3-12 items, You desire to have no empty space in the collection.
I assume that the Collections are stacked in a list?
When all the collections are at Max size, do you expect the operator to scroll down the group of collections?
From your description you are trying to avoid the case were there is more data off the screen which is not reviewed because of a large block of open space at the bottom of the collection. (Causing the operator to no look further down the list.
How do you deal with the condition that the group of collections exceeds the size of the display? Do you expect the operator to scroll in this case?
Let me take a look and see if there are any other options. Have you looked at using the Collection Section feature?
Here is a single collection with 2 groups each having three items:
Here is the same collection with updated rows to adjust the selection.
Does this meet your requirements
Regards,
Peter
@PEHOWE wrote:How do you deal with the condition that the group of collections exceeds the size of the display? Do you expect the operator to scroll in this case?
The collections and cells displayed can and will extend beyond the limits of the display window. I want the user to scroll the whole page as one.
That is what I have currently with each of the three collection containers on the page at a fixed size without individual scrolling. The issue is that each container has a varying amount of empty space depending on how many rows are returned by the data service feeding it.
I am aware of the container sections functionality but I haven't investigated setting that up; it would require some degree of reworking the data services that retrieve the data for collections. Possible I will just create a new helper service that combines each set of output into one table before passing to the collection.
My intention is to revisit the problem sometime this week; hopefully I can reach a better solution than my current workaround.
Replying to myself to update.
I implemented section functionality for my collection data and am now displaying all cells in one container/collection widget.
Unfortunately this still doesn't actually resolve the issue. The collection container still can not be resized dynamically to the size of its contents and the vertical scroll cannot be disabled for the container in responsive mode.
I can still of course set the single collection container to a fixed size but this puts me in the same situation of having empty space in the container when the collection cell set is less than the maximum. It's better this way than multiple selections with their own empty space but it still has the same issues.
Otherwise, with the single collection cell set to responsive I get a scrolling collection while the containers at the top and bottom of the page remain static. My issue with this is that it allows a user to see and press the "Submit Report" button before scrolling through all of the collection cells. A user who is unfamiliar with this behavior and/or the number of cells they should be seeing they may hit submit while having missed some cells. Validation could be used to disable or hide the submit but this is another layer of complexity I would rather not need.
I appreciate your help but unfortunately there appears to be no acceptable solution to the problem. Until a container can resize dynamically to its contents it looks like I'll be stuck with empty space in my smaller collection sets or using sub-optimal workarounds.
I'll be submitting a feature request for this.
Hello @CC_13244540,
AFAIK there's no way to make it properly dynamic.
If you're able to estimate the size of each cell on the server side, then you might get some results with CellHeightField property.
/ Constantine
I don't think this does anything for me. I already know my cell height needs to be 100px with no variation.
It is collection container size that needs to be variable/responsive and that can not be bound (as far as I can tell).
If I could set container size from a service or function it would be easy to get the number of rows returned by my data service and calculate that number of rows * 100px fixed cell height = required container size.
Oh I see! Sorry, misread your post. Seems like you have two choices:
1. Re-layout your mashup, so that the collection fills all available space (grow: 1), and all other widgets are on top of it and are shrunk as much as possible (grow: 0), OR
2. If you need some widgets below your collection, but you can't afford to always have them on the screen, you might be able to put them in a collection footer.
@Constantine wrote:Oh I see! Sorry, misread your post. Seems like you have two choices:
1. Re-layout your mashup, so that the collection fills all available space (grow: 1), and all other widgets are on top of it and are shrunk as much as possible (grow: 0), OR
2. If you need some widgets below your collection, but you can't afford to always have them on the screen, you might be able to put them in a collection footer.
1. Unfortunately placing all other widgets at the top of the page, above my collection, won't work really as it would place the "Submit Report" button at the top of the page, rather than at the bottom after all of the collection cells have been reviewed. I didn't test this layout, I assume it would be functional, but visually/UX-wise it's a non-option for me.
2. Unless I'm missing a property (I filtered the properties window to check) the collection footer property is only for Section footers meaning that every section of the collection would have the footer repeated. This results in my "Submit Report" button widget appearing three times in the page. This again is not an acceptable option for me.
I appreciate your help but unfortunately there appears to be no acceptable solution to the problem. Until a container can resize dynamically to its contents it looks like I'll be stuck with empty space in my smaller collection sets.
I'll be submitting a feature request for this.
I'm not sure I follow you.
You're suggesting putting my button widget in an additional cell of the collection?
How would I go about doing this? The collection widget uses the same child mashup for all cells.
Yes, I suggest you add the "Submit" button to that cell mashup.
In that cell mashup you can control the visibility of the widgets (or even their container) and the button via a couple of validators, which act on some "type" cell parameter. In your server-side code just do result.AddRow({ type: 'last' }); at the end of your service, and off you go. It is rather ugly implementation-wise, but quite easy to achieve.
You might need to figure out how to pass the Clicked event from the cell to the containing mashup, but there are several ways to achieve it, e.g. via setting a dummy session variable. Again -- not elegant, but will get the job done.
Thanks, I'll give that a shot.
Edit:
Yea that works perfectly. Bit of a process to setup fully but it works and looks right.
Thank you!