[development] Making a whole site location aware - a
drupal at mclewin.com
Tue Aug 22 06:15:00 UTC 2006
I've run into a problem that may be easily solved if one knows the right
SQL trick. How do I know when to apply my JOIN and WHERE clauses to a
given node query? I've run into a condition where my nodes with
locative data filter exactly as I want them to based on location, but
nodes without locative data don't show up (I know why - it is because I
INNER JOINED them with the location table, which yields no result). At
the point where hook_db_rewrite_sql is called, how do I know that I'm
dealing with a node that has location information?
If this thread has become inappropriate for the overall developers list,
I've placed a copy of it on http://mclewin.com/node/495. My
hook_db_rewrite_sql implementation is posted there as well.
Dave Cohen wrote:
> Write a module which stores this data however you see fit. (Could be a table
> you create that joins the users table on uid).
> Then, use hook_db_rewrite_sql to filter out any nodes which have location
> information which is not within the users radius. This way, your work
> applies to any node with location information, not just events. And the
> event (or any other) module does not have to change at all.
> If you take this approach, your module is essentially a location-based access
> control module. Read up on how node.module uses hook_db_rewrite_sql to
> filter nodes based on the node_access table and emulate that.
> On Thursday 17 August 2006 19:39, drupal at mclewin.com wrote:
>> I have a question for the masters. If you are an impatient master, jump
>> over the context and to the second to last sentence for the question.
>> Hopefully that is enough context for you. Here's the question: What is an
>> appropriate "well recognized location" within Drupal to keep these seven
>> pieces of information? (latitide, longitude, search radius (storage in
>> miles), country code, province, postal code and city.
>> I'm looking forward to having an answer (or seven :) ) so that we can get
>> closer to having patches in the patch queue.
More information about the development