Thanks. I didn't realize that SQLFORM was used by default to display a Row object; that makes sense. And the presence/invocation of those 'format' expressions is what's causing the various 'additional' SELECT statements I see in the "db stats" display, yes. By 'additional' I mean they're SELECT statements I didn't explicitly code. They're repetitive, but that makes sense if they're applying the 'format'.
On using represent or _format: thanks. I saw the 'represent' attribute and assumed (not good!) that that was 'automatically' called, and the results of that were stored in the Row object. I see now that, as you say, if it's not the entire Row then I can explicitly call the function, passing in the field value. Thanks. On Tuesday, September 11, 2012 11:27:32 PM UTC-6, Anthony wrote: > > Three questions: >> >> 1. What's the 'magic' going on that tells the display code for >> meetTeams to use the 'format' expression (but not to use it when >> displaying >> 'message')? Does it realize it's a row, and the row knows how to display >> using the format? >> >> When you create a reference field, if you don't give it any validator, it > will automatically get an IS_IN_DB validator, and its "represent" attribute > will automatically be set to the "format" attribute of the referenced > table. The "represent" attribute is only used by SQLTABLE (i.e., when you > include an entire Rows object in a view), SQLFORM, and SQLFORM.grid. If you > simply display a single value from a Row object, the "represent" attribute > is not used. > >> >> 1. Are the results of that 'format' expression stored in the row, >> available to me to use? As you can see I can explicitly join with the >> Institution to get the name. But if there's an easier way, then I'll do >> it. >> >> You can access the format expression either via db.Institution._format or > db.Team.Institution.represent (the latter is actually a function that will > reference the former). > > Anthony > --
