|< Day Day Up >|
Horizontal portals are one of the
Figure 16.6. Notice that the right-most portal has a scroll bar. That ensures that however many related records this record has, they will all be accessible to your users.
|< Day Day Up >|
|< Day Day Up >|
We've covered the basics of portals thus far, and discussed the idea that portals are used to display records from a related table and that the records
These relationships are often thought of as "primary." They're the relationships that you depend on to define and determine a database's
We will now venture beyond that one function and explore other uses of portals. The other, advanced uses of portals
Basic Selection Portals
The first advanced portal use that we discuss is what we refer to as a "selection portal." Selection portals are used to present choices to the user in lieu of a value list or menu of some kind (see Figure 16.7).
Figure 16.7. Notice that when using a value list you have to expose your internal IDs to users, and that the mechanism here can display information from only one other field.
Selection portals offer an alternative to the standard approach of using value lists to choose foreign key values.
The only way two records in an
For a refresher in related value lists, see Chapter 3, "Defining and Working with Fields," p. 63 .
Value lists, although a quick and easy means of giving users access to choose related records, can be limited: If you have hundreds of possible values, they can become cumbersome to scroll through. You're also able to display the contents of only two fields, the first of which needs to be the values for your match field. Some developers and designers sensitive to user interface issues feel that these key values expose too much of a database's inner workings to users who may be turned off by having to see and choose from what often are alpha-numeric codes meaningful only to the database itself. Figure 16.8 offers an alternative where users never see the primary keys of a database.
Figure 16.8. This portal of options allows users to pick which related record they wish to associate with their current record.
Selection portals address these issues, although admittedly requiring more work to build. When a user wants to associate a record, as shown in Figure 16.8, he need only click the "Rowena Lane" row in the selection portal. Notice that the example shows the selection portal in a different pop-up window. This is a common way to display a selection portal for only as long as it is necessary. Clicking on a row above can also close the window in question.
The basic concept for selection portals is
First define your data structure. In the example shown in Figure 16.8, agents can work with multiple listings, but a listing might have multiple
Figure 16.9. We've simplified the fields and relationships in this example to show just the primary data structure and a handful of fields necessary for the example.
To see this process work, first create an Agent layout and add a portal for all the listings associated with that agent. We recommend displaying your match key fields until you get comfortable with this technique.
Now you need a portal that shows all the listings in the table from which users can choose. For any portal, you always first need a relationship, so create a second table occurrence and second relationship. The example in Figure 16.9 related the primeID_agent to the primeID_listing via a Cartesian cross-product operator ( x ).
Note that it doesn't matter what fields you choose as match fields for a cross-product join. The operator doesn't make any comparison and simply
A second portal can now be placed on your existing layout or, in all
To review how to create a pop-up window, see "Rich Dialog Windows," p. 368 .
After your cross-product selection portal is in place, you need to write a script to associate the related record. The script, which will be tied to a button that's placed in the selection portal, needs to navigate to another layout to create the association. So that information about the current record and the selected portal row can be accessible on that other layout, you need to define the button to pass the agent and listing IDs as a script parameter. Use the following:
Select_Listing # # establish context Go to Layout [ "Transaction" (Transaction) ] # # create the new record New Record/Request # # set the two foreign IDs required. # This script assumes that the button that launches the script passes the script parameter: # Agent::primeID_agent & " " & select_Listing::primeID_listing Set Field [ Transaction::foreignID_agent; LeftWords (Get (ScriptParameter); 1) ] Set Field [ Transaction::foreignID_listing; RightWords (Get (ScriptParameter); 1) ] # # commit and return to the original layout Commit Records/Requests [ No dialog ] Go to Layout [ original layout ]
To review script parameters and how to pass multiple parameters, see Chapter 15, "Advanced Scripting," p. 421 .
This basic technique allows you to create a more complete user experience for your users and to expressly control the creation of related records. The advantages of this over a value list are that you can offer more than two fields of information to users, you can leave obscured the key values in your database, and
Portal Row Highlights
You are now exploring ways of working with portals that go beyond simply using them to display data that is related in a real-world sense. You're now establishing relationships that allow for other things. In the example in the
Figure 16.10. The highlighting gives solid feedback to users that they are acting on the row in question.
Notice that the Assign Selected button has been moved to the top of the portal, rather than placed on every row of the portal.
This technique involves setting a global field to the value of the primary key of whichever row the user clicks. You need three fields in all for this technique. We generally add them to the related table or a separate utility table, but keep in mind that you can use
Notice that in cases when
= the primary key of the related table, the calculation returns the value (in this case a colored rectangle) from
. Because you're using global fields, this solution works
The final element of implementing highlighted portal rows is to place the
calculation field in the portal itself. Make the field exactly the
One additional option when storing a selected row ID and creating a highlighted portal row is that it is possible to then also create a relationship
Consider the implications: You can display related record fields directly on your current layout, based on the selected row (see Figure 16.11).
Figure 16.11. Notice that the information on the right corresponds to the related record selected by the portal on the left.
This is a great way to address a portal that is getting too crowded with fields. Instead of making each column smaller, or perhaps stacking fields in rows that might then get difficult to read, simply allow users to select a row in a portal and then display additional information about the selected, related record off to the side.
Multi-keys and Multi-row Selections
In addition to wanting to highlight a single row, as in the previous example, you may encounter the need to have multiple rows selected at once. In the Agent Listings example, for instance, you may want to allow users to click multiple rows in the listing portal and assign them all at once to the agent in question.
This is a particularly handy way of allowing users to do multiple things at once: add a batch of listings to an agent, select multiple people for form
The technique for this is nearly identical to that already presented. However, we rely on FileMaker Pro's capability to resolve multiple match values in a single field. These multiple match value keys are often called multi-keys .
Consider a company table related to an agent table, as shown in Table 16.1.
Table 16.1. People
If you establish a relationship to this table by using a field ”global or
For example, if your company match field holds the following:
then your valid, related records will be Rowena and Kai's.
relates to Devlin, Erlend, and Nate. It doesn't matter to FileMaker in which order the values fall, simply that they are valid.
With a multi-key match, it is possible to show multiple rows as highlighted or selected in a given portal. You can use again the same three fields you'd use to set up a single row highlight:
If you are modifying the fields from the example given earlier in the chapter, notice that the test in the calculation is now using a FilterValues function that recognizes whether or not an ID is included in your global (as opposed to simply checking whether the two fields are equal).
When setting values in gSelectedRowID , a simple Set Field script step won't do the trick any longer. Doing so would replace the contents of the field and you'd be left with just one row selected. Your script needs to look like this:
SelectRow_SetHighlight # # if the ID already exists, remove it If [ FilterValues (Listing::gSelectedMultiRows; select_Listing::primeID_listing) ] Set Field [ Listing::gSelectedMultiRows; Let ([ selectedRowKey = select_Listing::primeID_listing & "" ] ; Substitute (Listing::gSelectedMultiRows; selectedRowKey ; "")) ] # # if the ID doesn't exist, append it to the end Else Set Field [ Listing::gSelectedMultiRows; Let ([ selectedRowID = select_Listing::primeID_listing & "" ] ; Listing::gSelectedMultiRows & selectedRowID) ] End If # Commit Records/Requests [ No dialog ] #
|< Day Day Up >|