Wesley, Thank you for the response, this is exactly how I have come to think of the PostalAddressProperty, I would like to suggest that the documentation be more clear on the purpose of the object, it is not clear from first blush that this object is not a more rich interface to the more Geo aware google functions.
I would also like to propose a higher level address object that takes an address string and automatically separates it into fields and geo codes the address, much like entering an address into maps.google.com. This object could throw and error on ambiguous results which the developer can handle to resolve the ambiguity. On Dec 29 2009, 12:10 pm, Wesley Chun <wesc+...@google.com> wrote: > greetings! > > as far as i know, and please correct me if i'm wrong here, you can > indeed just use a StringProperty if you wish. however, you can think > of PostalAddressProperty as more of a "classification" as far as what > *type* of string it is (sort of like metadata). > > it is also useful for interfacing with other Google Data Protocol > objects, and, as you mentioned, outputting to the gd: XML namespace, > meaning that it is supported across other Google APIs and tools, i.e., > Google Calenar, Contacts, Open Social, etc.), which *may* perform some > validation or search criteria. > > and your suggestion for making individual fields, thus orderable and > sortable, then creating a full object on the fly for gd: output sounds > like a reasonable workaround. for more information on postal addresses > via Google Data, > see:http://code.google.com/apis/gdata/docs/1.0/elements.html#gdPostalAddress > > best regards, > -wesley > > > > > > On Mon, Dec 28, 2009 at 4:49 PM, Kelly A <kelly.j.ander...@gmail.com> wrote: > > If you cannot query on or sort on the individual fields of the address > > it is rather useless. I could just store the field as text. I assume > > that the major advantage is that you can export the item in the gd: > > XML namespace with out doing any extra work. That being said, I would > > think exporting the address in a way that google contacts can read the > > address is far less important that being able to sort by zip code, > > state, city, etc... > > > For those searching for an answer to the question of querying on a zip > > filed in a PostalAddressProperty or sorting on a field in a > > PostalAddressProperty, the overwhelming answer I have come across is > > you cannot. It would seem that the best solution is to store the > > address fields in individual variables and when a request for a gd: > > address or full address is made, construct the PostalAddressProperty > > on the fly. > > > Perhaps the PostalAddressProperty is not documented in a way that > > allows me to see the value, or all of the sample applications simply > > make no use of addresses and I am just missing the point. If others > > have any examples of the value of this object please do respond. > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > "Core Python Programming", Prentice Hall, (c)2007,2001 > "Python Fundamentals", Prentice Hall, (c)2009 > http://corepython.com > > wesley.j.chun :: wesc+...@google.com > developer relations :: google app engine -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
