I am trying to figure out / remember how to have a repeating group filling up the vertical space while having a detail sidebar.
When scrolling up and down the repeating group should move (RG is sandwiched between table header with a search bar and table footer with paginator), the sidebar reveals the details of the row that is clicked.
Currently the scrolling action will scroll everything (repeating group AND side bar), and when we click on a row low on the RG we have to scroll up and up to see the details in the sidebar. Thatâs not handy.
I have a few ideas. One option would be to make the repeating group look like two separate sections by controlling its visibility so that it appears over the sidebar when needed.
To do this, you could create a few groups in the header with specific fixed widths, making sure the relevant columns remain aligned and visible when the repeating group is displayed over the sidebar.
Could you share some screenshots or a simple diagram of your current layout? That would help us better understand what youâre trying to achieve and suggest a more appropriate solution.
I have a plugin called dynamic width and height that makes this easy. Can reference heights of other elements to set height of one. The most difficult part of your design is the sidebar being under the header and the use of a footer element.
My suggestion is first try on test page, no header no footer, see if just RG and sidebar do what you want. Then add a header and last the footer. Footer is issue for sidebar as footer is not always visible so sidebar height needs to adjust when footer visible or not.
you can simplify and not use a footer. Pages like this are typically a dashboard of sorts where footer is not important.
Are you suggesting to place a group into a repeating group that will display transaction details of a selected transaction? So RG has a âtransaction cardâ that is snapshot of transaction with select checkbox and a second group in the RG to show full details of the selected transaction?
I think for this approach, it would be betterâand should also improve performanceâif the Transaction data type (Iâm assuming that is the name of the data type you want to display) had a field such as Summary, containing the information you want to show in the sidebar.
No, that would not be a good approach. Usually the details of a transaction are not stored on a data field called summary. Normally the fields that are shown in a details view are fields that make up the transaction data type.
A âcardâ used to select a particular transaction would be just a few fields, but details view likely shows all fields.
Also if you put a group inside a repeating group, itâs in a single cell. So if you have a list of 10 transactions, each is one cell, so if you then show a long group containing all details of a selected transaction, the height expands the cell of the RG, so you would not likely see any other transactions as a list since one cell would have an expanded height.
Transaction details needs to be in a container, outside of the RG. It should be a group so that when no transaction is selected the RG width takes up screen width and when transaction details shown the width of RG shrinks to give horizontal space to the transaction details group.
The intention behind my suggestion was to solve the problem by creating a Summary field containing the complete transaction data (essentially combining the other fields). This could speed up data processing instead of running a Do a search for each individual field. It would address the issue described in the second paragraph, even though it would duplicate some data.
I honestly hadnât considered the point you raised in the third paragraph regarding the row height. Youâre right: increasing the height would affect the entire row/cell and therefore change how the RG is displayed. From a design perspective, thatâs definitely not the best practice.
I also hadnât understood that the Repeating Group would sit underneath the sidebar. It would be possible to change how the main cells are displayed when the sidebar is expanded (considering my proposal of using only one Repeating Group), but again, I believe there are better design solutions.
My suggestion was mainly intended to help him solve the problem as quickly as possible and then evaluate how well the approach works after implementation.
That suggestion would do opposite of speed up data processing. Reason is that we do not search for individual data fields, we search for data types and bubble returns all fields on the type except thosee protected by privacy rules. So duplicating fields into one summary field will result in higher WU costs and longer data processing speeds because there would be essentially twice as much data than needed.
Youâre right, but having this Summary fieldâcreated or updated whenever a new Transaction is createdârather than using Do a search for, either in the RG or in the sidebar, would avoid running a new search every time the user requests to view the information.
The user could even create a new Data Type related to the Transaction and use it as the data source for the sidebar. However, that specific solution would not be suitable if the goal is to display all the data using only a single Repeating Group.
No. The data is already available because itâs in the RG already, that is how the RG shows list of all transactions, it loads them. Then when you select one you do not need to search again, you might set it as a custom state, a url parameter or display it as a groups data source.
This would cause double the WU for every creation or update to a transaction and an extra search on every selection of a transaction to see details, further increasing unnecessarily the WU involved and causing slower performance.
Thatâs a good ideaâusing custom states could work well here too.
Now I think the creator of this post has at least three different options to try.
Thanks for all the contributions. This discussion helped me as well. Iâll take a look at your plugin later and see whether I can use it in some of my apps.
