So it seems that you could have a case where the fields are mostly from different tables, and then it might not be that easy to decide which one would be most informative to select as the underlying table occurrence that will appear in the label in layout mode.Īm I on the right track with the “mental model” I’m developing of this? Thanks. My description would be that every column in a portal represents a field from some related table, but they can all be from different related tables (and in fact none of them have to be from the underlying table occurrence as far as the portal’s function goes, although I think it would be a mistake to set it up that way). I think you’ve answered my question by saying that having the “underlying table occurrence” appear as a label on the portal in layout mode is useful to the developer, but will not affect the behavior of the portal if it gets changed.īut since I’m now at the point where you were in FM3 (experimenting to learn how portals work) maybe you won’t mind if I ask you to elaborate on your comment that “every row in a portal represents a record in a table”. It seems to me that it would be nice to be able to dynamically sort the portal by clicking on the column headings, with a little indicator appearing to indicate ascending or descending. And as the “part 1” implies, we’re not done looking at portal sorting yet. You can grab a copy of this article’s demo file, portal-sorting-part-1, if you are so inclined. Here’s what the sort order now looks like from within Portal Setup:įinally, we return to browse mode, locate a product that has repeat customers, and we see that the portal is sorting as per our new criteria.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |