In the lately deprecated tables API, if it had ever worked the way I read that it was intended to work (which it once did), one wouldn't ever need to discover the column names by reading the header row. Instead, one would say something like the following when defining a table:
*in future, for my own convenience, I will refer to column B as 'Description'" The next day, when some sensible spreadsheet user inserts a column to the left of B and renames the new C1 to "Item Name", your app doesn't break. Just like a named range, the sheet adjusts the reference so that the name your code relies on - 'Description' - now refers to column C ... and further, while the name your code chose and the value of the header cell C1 are now different, it's no big deal - the column has the same *semantic* meaning. You're just isolated from changes in its position and its user-facing description. How nice would it have been? Very nice. We could even have defined table P to include columns A-F, and table Q to include just columns A and E (useful since the Spreadsheet API doesn't support partial response/update). Instead, Google screwed it up by introducing a two-way binding between the name the application chose to refer to the colum, and the value of the header cell. Oomph. Quick - back to the cells feed to see if we can work out (somehow) what to call these columns when addressing them via the list feed! All kinds of wierd behaviour ensued (I could point you to a few bugs I personally filed), among the worst of which was the stupid, stupid message "This operation is not permitted because it would alter the structure of this table" when the spreadsheet user tried to do such nefarious things as oh, fill-down a formula cell, or cut and paste a range. Having thus reduced the grand concept of tables to an annoying repetition of the List API, some grown up in the playground obviously canned it. And now we are stuck with this rigmarole of *looking up* the column names ... and Google are 'considering a feature that would allow you to fetch the header row'. Just let us bind our application-specific names to column indexes already, and adjust them the way you do named ranges. But it's like talking to a brick wall ... David. On Mar 16, 6:38 am, Vic Fryzel <[email protected]> wrote: > Unfortunately, at the moment, you must use the cells feed to accomplish > this. I'm considering a feature that would allow you to fetch the header > row with the lists feed, but I don't have an ETA yet. > > -Vic > > On Fri, Mar 4, 2011 at 9:56 PM, Jason Cipriani > <[email protected]>wrote: > > > > > Using PHP Zend bindings for spreadsheet API. > > > If I have a WorksheetEntry; I can use getContentsAsRows() to get all of the > > entries in that worksheet's list feed. > > > The keys in each list entry are the column headers converted to lowercase > > with all non alpha-numeric characters stripped out. > > > How do I get the real column names for this worksheet entry, and the > > corresponding list entry keys for each column? Alternatively, a way to get > > the real column name given the list entry key would work too. > > > My goal is to be able to both display the real column header text > > (spreadsheet column headers are Google Forms questions) to the user of my > > application, and also to know what the list entry key is for each column so > > I can display the values of the columns as well. > > One way I've been toying with is to use a cell feed to get the first row > > and read the headers that way. > > > But then, how do I build a correspondence between the column headers and > > the list entry values? > > > Am I guaranteed that the values in a list entry will be returned in > > left-to-right GUI order, and empty values will be present (value count will > > be equal to column count)? > > > Being able to display the column headers and the corresponding values in an > > application seems like a very reasonable goal, I feel like I'm missing > > something because this is surprisingly clunky... > > > Thanks! > > Jason- Hide quoted text - > > - Show quoted text -
