Problem to return to select row with a portal inside a tab

[Morenomdz]

Hello there, I am trying to build a layout that have a tab control, in each tab control I have a variation of the same portal, each set to a different filter, lets say three tabs with a portal in each. The filtering works fine and all that but, on that layout to the right I am trying to setup an "expanded view of the record", so if in the portal I show only about the five main fields, on the right side of the layout I want to show many other fields from that record. I've got that working by set a button on the portal row that:

Set Variable [ $PortalRow; Value:Get(ActivePortalRowNumber) ]

Go to Related Record [ From table: “MadOsApps”; Using layout: “OsAcc” (MadOsApps) ]

Set Variable [ $DashOs; Value:MadOsApps::OS ]
Insert Calculated Result [ MadTuto_search::Filter_Orc; $DashOrc ] [ Select ]

Set Field [ MadOsApps::OS; Evaluate (MadOsApps::OS) ] Commit Records/Requests [ Skip data entry validation; No dialog ]

Go to Object [ Object Name: "Tabbusca" ]

Go to Object [ Object Name: "TabPortalbusca" ]

Go to Portal Row [ $portalrow ] [ Select; No dialog ] 

The script above has only one field set to "copy", the real one has about 12 fields.

What the script is suposed to do is set a var with the current portal row, go to the related record using a layout that has all the fields I need, set a var for each field, go back to the main layout, paste those in their related (global) field to just show the extra data, go to the specified tab, go to the specified portal and then based on the portal row var go to that row.

The issue is, it always go to the right row but on the portal on the very first tab. Is that a bug or a limitation of the function?

Ideas are welcome as well if you guys can think on a different aproach to get the info from those related fields I need without having to change layouts, so in that way it would never uncheck the right portal row.

Thanks!!

I just rebuilt the script and it worked, not sure where was the error. Still, if you guys know a more elegant way to achieve this idea I would love to know it! ><

Edited May 9, 2015 by Morenomdz

[eos]

tI am trying to setup an "expanded view of the record", so if in the portal I show only about the five main fields, on the right side of the layout I want to show many other fields from that record. […] a more elegant way to achieve this idea I would love to know it! ><​

Unless you have requirements we're not privy to, you're going about this the wrong way.

The paradigm of a relational database is to NOT COPY data (except in certain scenarios where you need a ”snapshot in time“), but to create relationships that lets you point to these data to display them, or even edit them “in place”.

The common approach to your List-Detail scenario is to:

• create a field in YourParentTable that will serve as a selection key (same data type as the primary key of YourChildTable) 
• create a new TO of YourChildTable, say, YourChildTable_selected
• create a relationship YourParentTable::selectedChildKey = YourChildTable_selected::primaryKey
• put the desired fields from YourChildTable_selected on the layout (don't need a portal, since there is only one related record via this relationship)
• place a button into your portals to
• set the selection key field to the primary key of the current portal row

i.e. you

• can (more or less) reduce your script to a one-liner Set Field [ YourParentTable::selectedChildKey ; YourChildTable_portalTO::primaryKey ]
• won't have any issues returning to the correct portal, because you don't leave the layout in the first place
• don't need any global temp fields, because you
• don't needlessly copy/move data

Edited May 9, 2015 by eos

[comment]

Alternatively, you could place the selected record's unique ID in a global $$variable, then use this variable to filter a one-row portal, based on the existing relationship. This way no additional fields or TOs are required.

You could even make a different selection for each parent record, and have these selections persist until the end of the session - see a demo here:

Note:

The issue is, it always go to the right row but on the portal on the very first tab. Is that a bug or a limitation of the function?<

​We cannot tell from your script what the problem is. You have two Go to Object[] script steps in succession. Obviously, the first one of these is not doing anything useful. If the Go to Object[] step immediately before the Go to Portal Row[] step selects the correct portal, then this issue should not exist. But, as explained above, this is not a good approach to take overall.

 

[Morenomdz]

Thanks for the info, I am really new on this and still learning how to use and how to get the best from related tables and stuff. Just to clear up, what I want is something that stays in the same layout, with a list of records based on a criteria, but as these records have to many fields, I set the portal to show the main identification ones and only if the user needs extended info he will go to the record. Using normal portals with all the fields would have a huge horizontal layout and thats is what I am trying to avoid, to not use a layout specific to the record I was thinking on something like this:

The idea is to only show that extra info on the selected row. Now I have some questions:

* Will the layout download the data for the whole table when I go to that main layout or just those specific ones I set the list of Var to copy? In my head that was a "cheaper" way to go as it was copying just and only the select row info. I was thinking, maybe having a button next to the end of the row "show more" and only then it would load the side window?

*Would be a better aproach to have an equal layout on the main table that instead of having the tabs it would show the full info of the record? The idea is having the feeling that the whole layout of that dashboard is not changing at all.

Abusing a little bit, what is the best aproach to use on the relation here?

A Global field on both tables with same text, then with an "=" relation between these set multiple portals with different filters;

A relationship for between the tables for each portals, in this case 5 relationships each one with specific text on the portal side table to filter that specific data; (Using that one)

A single relationship between the ID field on the main table and the ID field on the portals table with a "X" relationship to show it all.

Thank you very much for the help here, I am working on understanding the whole relationship procedure and it opens up to many ways to work with the program.
 

[Wim Decorte]

If you built your layout on the target table itself as a list and use a popover for the extra fields you would not need relationships at all.

And your filter to build the list view becomes just a regular find.

Edited May 9, 2015 by Wim Decorte

[Wim Decorte]

 

A Global field on both tables with same text, then with an "=" relation between these set multiple portals with different filters;

 

​

That does not work.  You can use a global on the "parent" side of a relationship but not on the child side.  Globals can not be indexed.

[Wim Decorte]

 

A relationship for between the tables for each portals, in this case 5 relationships each one with specific text on the portal side table to filter that specific data; (Using that one)

 

​

Not a good idea obviously since you'd have to create a new relationship if you ever want a new filter.

[Wim Decorte]

A single relationship between the ID field on the main table and the ID field on the portals table with a "X" relationship to show it all.

 

Based on the mockup and assuming that the left list is a portal and so is the right block then you'd two relationships:​

 

1) to all records, probably using an X relationship and a filter on the portal itself --> keep in mind that "x" relationships can be expensive if there are a lot of related records

2) a relationship from the "selected" row on the left to the that record.  You can set a "selected ID" global and relate it to the ID of the target table.

 

[Morenomdz]

Based on the mockup and assuming that the left list is a portal and so is the right block then you'd two relationships:​

 

1) to all records, probably using an X relationship and a filter on the portal itself --> keep in mind that "x" relationships can be expensive if there are a lot of related records

2) a relationship from the "selected" row on the left to the that record.  You can set a "selected ID" global and relate it to the ID of the target table.

 

​With 2, yes the left block is a portal, how would I get the fields to display as a vertical block like on the image instead of the horizontal only that portals do? 

[Morenomdz]

​

That does not work.  You can use a global on the "parent" side of a relationship but not on the child side.  Globals can not be indexed.

​Would an auto insert text ID field on both tables work? What would be the best way to achieve this in your opinion??

Thanks!

[comment]

​how would I get the fields to display as a vertical block like on the image instead of the horizontal only that portals do? 

​Make the right-hand side portal show only one row. Make that row tall enough to accommodate a block of fields arranged vertically.

 

Abusing a little bit, what is the best aproach to use on the relation here?

A Global field on both tables with same text, then with an "=" relation between these set multiple portals with different filters;

A relationship for between the tables for each portals, in this case 5 relationships each one with specific text on the portal side table to filter that specific data; (Using that one)

A single relationship between the ID field on the main table and the ID field on the portals table with a "X" relationship to show it all.

​There is no best approach, it all depends on how many records do you have (or expect to have) and what is the purpose of showing them in 5 groups. However, there are really only two options: (a) filter a relationship or (b) filter a portal. Filtering a portal is easy to set up, and it also enables filtering on criteria that are not stored in the child table; OTOH, this incurs costs in performance.

Note that filtering a relationship does not necessarily mean you must have a dedicated relationship for each group. You can filter a relationship by having a global field on the parent side, matching a "category" field (stored) on the child side. Then just change the content of the global field in order to change the group being shown.

 

 

Based on the mockup and assuming that the left list is a portal and so is the right block then you'd two relationships:​

​Or just one, as I explained earlier.

 

 

 

 

Edited May 9, 2015 by comment

[Morenomdz]

Alternatively, you could place the selected record's unique ID in a global $$variable, then use this variable to filter a one-row portal, based on the existing relationship. This way no additional fields or TOs are required.

You could even make a different selection for each parent record, and have these selections persist until the end of the session - see a demo here:​

Liked the idea, I am trying to setup a button on the portal rows itself that will set the $$var based on the IDfield on the main tablle, I am getting the correct field ID, but not getting the second (on field) portal to filter based on that ID, am I suposed to do something else than setting it to filter by my set $$var?

Edit: Nevermind got it working by setting portal to $$var = Idfield, also had to add the refresh lines "Set Field [ MadOsApps::OS; Evaluate (MadOsApps::OS) ] Commit Records/Requests [ Skip data entry validation; No dialog ]" to get the script to work instantly, all good! Now moving on checking if I can trim the relantionships, delete this whole mess I did and build it up from the zero with the propper settings all over.

Thanks for the help guys, great times aver!!

Edited May 9, 2015 by Morenomdz

[Wim Decorte]

​With 2, yes the left block is a portal, how would I get the fields to display as a vertical block like on the image instead of the horizontal only that portals do? 

​You don't need a portal for the vertical block.  There is always only going to be one related record so you can just use the related fields without a portal.

Even with a portal it would work, just create a one-row portal and make it high, then fit your vertically stacked fields into it.

[Morenomdz]

​You don't need a portal for the vertical block.  There is always only going to be one related record so you can just use the related fields without a portal.

Even with a portal it would work, just create a one-row portal and make it high, then fit your vertically stacked fields into it.

​That was my idea but having just the fields outside of a 1 row portal don't show the related record that I have selected on the first portal, it will show the very first record on the main table. Perhaps I have a bad relantionship set or am I using the wrong field type on the layout?

[Wim Decorte]

Field type on the layout has nothing to do with it.  It sounds like a bad relationship.

Here's how the flow typically is in a scenario like this:

- user clicks on a portal record on the left

- your script grabs the primary key for that selected record, puts it in a global of the table of the layout you are on

- there is a relationship from that global to the primary key of the records shown in the left portal

- that relationship will yield just one related record to show on the right (since primary keys are unique)

[eos]

[…] Here's how the flow typically is in a scenario like this: […] 

​Which brings us full circle to Saturday, 11:21 AM … 

Edited May 11, 2015 by eos

[Morenomdz]

Field type on the layout has nothing to do with it.  It sounds like a bad relationship.

Here's how the flow typically is in a scenario like this:

- user clicks on a portal record on the left

- your script grabs the primary key for that selected record, puts it in a global of the table of the layout you are on

- there is a relationship from that global to the primary key of the records shown in the left portal

- that relationship will yield just one related record to show on the right (since primary keys are unique)

Well the chance are this relantionship is set wrong as the only I got the main portal working was with Fieldid on main X fieldid on the "dashboard" table... Then all the portals I make on the "dashboard" worked but still not getting the infoinfo from select record to show on fields set outsider of portals. 

I am learning a lot here, bit will need some trial and error to get the relationaship mechanics inside my brain!

[Morenomdz]

Field type on the layout has nothing to do with it.  It sounds like a bad relationship.

Here's how the flow typically is in a scenario like this:

- user clicks on a portal record on the left

- your script grabs the primary key for that selected record, puts it in a global of the table of the layout you are on

- there is a relationship from that global to the primary key of the records shown in the left portal

- that relationship will yield just one related record to show on the right (since primary keys are unique)

​I actualy have to refresh window (or set a field to evaluate itself maybe) to the fields "on the right" to update or am I doing something wrong, again?

I am not sure if I understood you exactly but what I tried here, with two tables Main, that has all fields and Dashboard that will have the layouts:

____________________

 This "X" relation between the tables ID fields, with that I can have the portals show all fields and filter based on my drop down lists etc, all good.

 Then I have a script on the portal row that on click will get the ID field of the record in that row set as $$id, and go to an object on a slide on the right, that shows  this 1 row portal with fields from the Main table filtered by $$id and then refresh window so it updates the portal with the selected row. Works good.

_____________________

Then...

 For the sake of learning I was trying to understand why I couldn't get to show to content from the record selected on fields related to the main table outside of the  portal, so the way I got it to work was by setting that script that ran when a row is selected to set the ID field on the Dashboard table as $$id, that worked when I set  a second relation with the main table where Main ID = Dashboard ID, but then the question, isn't it easier to just use a second portal and not have to use a second  relation? Any of the two options is "cheaper" processing and time wise?
_____________________

Sorry for the wall of text, trying to understand it here. Thanks again!

 

[Wim Decorte]

If you are worried about performance I would no relationships at all.   An "x" relationship can be expensive if you have many records.  Because a portal forces FMS to send you a lot of data.

If build your layout as a list on a "Main" TO then you can save a lot of that data traffic.  You can then display the selected record's field either in a popover, in the header or the footer.

[Morenomdz]

The portal filters and dynamic filters I have set are just to good to pass, I will work like this for a while and see how performance goes as I get more and more records one, but will work on a plan b with something around what you suggested. 

Thanks!

[Wim Decorte]

The portal filters and dynamic filters I have set are just to good to pass,

​That's a dangerous mind-set.  Don't be married to your code.  Otherwise you'll probably find yourself turning to workaround after workaround just to keep the original bit of code in place.

[Morenomdz]

Not the code no, the final function, the idea of being able to filter records on the fly based on a text field you know, at first I used a list layout and had options to perform searches to filter the records based on specific criterias, then another layout to search etc, then I figured that having a portal with a changeable filter could do that in better ways while keeping the layout cleaner, so far I am liking more this aproach, but as always I am just learning it, whatever feels it will work better I am not afraid to try!