Jump to content

Recommended Posts

Posted

There's been various forum posts regarding a similar topic, but I can't seem to crack this query.

Here's my data structure:

/companies/

  /company-1/ (company.php)

  /company-2/ (company.php)

  /company-3/ (company.php)

/people/

  /person-1/ (person.php)

  /person-2/ (person.php)

  /person-3/ (person.php)

The company.php template has a Page field (asm-select) called "people" which grabs all the people from /people/.  Therefore, a company can be assigned many people. (note: technically this could be done in reverse... meaning I could create a Page field called "companies" and assign that field to the people.php template, but the approach I'm taking makes more sense I believe... can control sort orders, etc.)

Now, let's say I want to do a query and find People whose first name is 'Joe' and who belong to a company with the word "Test" in it.

$companies = $pages->find("parent=/companies/,template=company,title~=Test");
$people = $pages->find("parent=/people/,template=person,first_name=Joe,XXX=$companies");

The part where I wrote XXX is where I'm lost. XXX would represent a belongs_to relationship like in Ruby on Rails.

I mentioned above that I could setup the fields in a reverse way, which if that were the case, this query would be easy (but create other organizational issues), however I want to stick to the approach field approach.

I know there's a lot of ways to go about this.

Perhaps I'm also overlooking something very obvious too.

Edit:

This post is the most relevant to what I'm discussing: https://processwire.com/talk/topic/1071-page-fieldtype-two-way-relation/

Posted
// Single company
$company = $pages->get("parent=/companies/,template=company,title~=Test");
$people = $company->people->find("first_name=Joe");

// Multiple companies
$companies = $pages->find("parent=/companies/,template=company,title~=Test");
$people = new PageArray();
foreach($companies as $company){
  $com_people = $company->people->find("first_name=Joe");
  $people->import($com_people);
}
$people = $people->unique();

Pagefields are only single direction, which sometimes is not the most convenient.

  • Like 1
Posted

I mentioned above that I could setup the fields in a reverse way, which if that were the case, this query would be easy (but create other organizational issues), however I want to stick to the approach field approach.

I actually think the reverse way would make more sense. Because you are likely to add more people than companies, and like this you have to edit only one page when adding a person. Also, the list in the asm field is also likely to be shorter this way.

and...

Now, let's say I want to do a query and find People whose first name is 'Joe' and who belong to a company with the word "Test" in it.

With that system you could use a single query for this:

$people = $pages->find("parent=/people/,template=person,first_name=Joe, company=$companies");
  • Like 2
Posted

Thank you for the variation in answers.

I wonder if this could become a core feature.

Pseudo-code off the top of my head:

$people = $pages->find("parent=/people/,template=person,first_name=Joe,referenced_by_template=company,referenced_by_field=people");
Posted

Both ways make the most sense :-)

Did that today with groups and products, looks like it works great.

You need to adjust names and stuff and you should be up & running (bidirectional)

I just implemented this approach based off of your code.  I like the bi-directional concept behind it, although data is being stored twice.  I can live with that.

Posted

A little bit more data will simplify search queries and results in less overhead.

And for end users it's convenient to be able to edit on 2 places.

ps, when you discover a bug, please report :-)

  • Like 1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...