Jump to content

Modelling data in PW (page relations)


SiNNuT
 Share

Recommended Posts

I'm working on a site redesign and migration from MODx to PW for a foundation that organizes cycling races. The site itself is fairly simple and the content not that much.

Talking about the site we figured it would be pretty neat if there was an easy way for us to manage the cyclingraces and its participants from the PW back-end.

Some numbers:

- For now it's two to four Races a year but this could grow

- A typical Race is ridden in Teams. Dependend on the type of Race Teams consist of 3 or 6 Riders. There usually are between 25 and 40 Teams and between 120 and 180 Riders.

- Participating Teams are numbered (1,2,3..) each rider gets a startnumber (1-6, 7-12, 13-18..)

At any given time a Rider belongs to one team, but ofcourse can belong to many over the course of the years.

Sometime before the race teammanagers start to email or even snailmail provisionary lineups.

So the typical use is this (via PW backend): A foundation member adds a Race and all it's info. He can also add the participating teams with their corresponding line-ups. On the front-end all of this info is displayed and up to date. Later on it would be really nice if a team manager could login to a page on the frontend where they can manage their line-up themselves.

Simplified, and maybe not correct at some points, this would look something like this in a more traditional db schema (see pic below)

I thought about adding Teams as children of a Race and the Riders as repeaters but although this works quite nicely from a ui perspective this isn't the way to go.

I not looking for a definitive answer but if someone could give some tips or thoughts on how they would approach this it would be great.

wcburgum.png

  • Like 1
Link to comment
Share on other sites

for this kind of relations i think the best way is to use the Page FieldType. you can put one on the race template where you can choose the teams, and one on the teams template where you can choose the people.

Link to comment
Share on other sites

I agree with diogo. I'd make a Race template that has a MultiPage field that link to Teams, and have the Team template have a MultiPage field linking to Riders.

Edit: I meant to use the MultiPage fields rather than Pages in Repeaters. Cleaner interface that way and slightly cleaner setup and code.

Link to comment
Share on other sites

I agree with diogo. I'd make a Race template that has a Repeater containing Page fields that link to Teams, and have the Team template have a Repeater containing Page fields linking to Riders.

He never mentioned repeaters, but they certainly are one option, especially for the startlists if I understand that one right.

It's definintely possible to do all of this with the Page fieldtype and a few templates.

Things like the Nationalities could even be one of those Page fieldtypes where the user can add new entries to the list from Riders template for example, though you have to bear in mind that you can only add a title that way and you'd have to add the code afterwards. Might just be easier to populate the nationalities in advance and have it as an autocomplete field instead.

I don't think you would really have a problem with any of this in PW. Looking at your diagram, every table there is simply a different template and all you have to worry about is how to make them work together.

Link to comment
Share on other sites

Hi Pete

Looks like you posted just before I edited my post :) Repeaters should work, but I think they are a bit clunky compared to using a Page field that can have multiple pages selected for this case. I'm still new to ProcessWire and forget bits and pieces easily :D

Link to comment
Share on other sites

At any given time a Rider belongs to one team, but ofcourse can belong to many over the course of the years

I agree with what the other guys said, but also wanted to add a note about the statement above. Since the rider belongs to one current team, you could make their parent page their current team, and have a multi-page reference reflecting their past teams. However, if these things will ultimately be public/indexable web URLs, then it's better to keep them in permanent spots in the structure and use page references for everything. That way the same URL can always access the same rider, regardless of time. Does something like a nationality ever change? If not, that may be a suitable parent for riders. I like having some structure where possible, rather than using page references for everything, but if everything can change then only use structure if changing URLs are acceptable (usually they wouldn't be).

So far I'm thinking that you won't need/want to use repeaters for any of these needs.

This sounds like a fun project. :) Especially with the Tour on now.

Link to comment
Share on other sites

Wiggins was on a roll today!

On topic:

Let's assume a rider has a permanent location (/riders/rider-name) and currently no team, because he retired last year. How would you structure this so you can output a list of former teams? And how would this be done so a team can show it's former members as well?

Perhaps a checkbox 'retired' and assume the first (or last) team in an array would be his latest? I thought about this a while ago, but never came to a satisfying solution.

  • Like 1
Link to comment
Share on other sites

Everyone thx for the responses. It's quite interesting to see what i can come up with in PW. You have to structure your data well and on the other hand it has to be as easy as possible from a data entry/UI point of view.

@arjen This is indeed an interesting question. I'm having a look at other sites how they approach this. Examples are http://www.cqranking...r.asp?riderid=7 and http://www.cyclingnews.com/teams/2012.

They seem to take an approach where they have a Team(code) and for every calendar year they list the riders. On a Rider page you can see their current team and past teams. If he's not associated to a team in the current year i guess they are considered inactive.

So i'm thinking about doing the Riders and Team like this, where every rider is a page and from every year page of a team link to the riders via a page field.

Teams: 		Riders:
 Team A	 Bradley Wiggins
-2013	 |
-2012----|
-2011	 |
 Team B	 |
-2013	 |
-2012	 |
-2011----|

Now to manage participants for a Race it's not as simple to just link to a certain team-year page. This is because a team can have for example 15 riders and only 6 are allowed to enter the race.

I'm not sure i will be able to pull this off completely because my coding skills aren't really up to par but it sure is fun fooling around with it.

Link to comment
Share on other sites

Let's assume a rider has a permanent location (/riders/rider-name) and currently no team, because he retired last year. How would you structure this so you can output a list of former teams? And how would this be done so a team can show it's former members as well?

I would probably make current_team a single page reference, and past_teams a multi page reference. Meaning, two separate fields. Lets say that $team is a Page with the current team. A team could find it's current members like this:

$riders = $pages->find("current_team=$team");

and past members like this:

$riders = $pages->find("past_teams=$team"); 

I know I said before that I didn't think there was a place for repeaters here. But now I take that back. Here's an alternate approach that might be handy by using repeaters: You could setup a repeater called 'teams' and have it contain these fields:

  • team (single page reference)
  • year (integer or page reference)

Then you could find all current members like this:

$riders = $pages->find("teams.team=$team, teams.year=2012"); 

and past members like this:

$riders = $pages->find("teams.team=$team, teams.year<2012"); 

The other option you mentioned: retired checkbox with first or last being current, also seems like a fine way to go. But that does make it harder to quickly differentiate between current and past teams, at least from the context of $pages->find(). So I think it may be better to use one of the options above.

Now to manage participants for a Race it's not as simple to just link to a certain team-year page. This is because a team can have for example 15 riders and only 6 are allowed to enter the race.

If you use the repeater approach mentioned above, you could add a checkbox to the repeater that indicates they are a participant. So if you wanted to find all partipants (the 6 rather than the 15) for $team in the year 2012:

$participants = $pages->find('teams.team=$team, teams.year=2012, teams.participant=1"); 

Lets say you wanted to output a table like your example link: http://www.cqranking...r.asp?riderid=7

Here's roughly how you'd output that:

$rider = $pages->get("name=lance-armstrong");

foreach($rider->teams->sort("-year") as $team) {
 echo "<p>";
 echo "Year: {$team->year}<br />";
 echo "Team: <a href='{$team->team->url}'>{$team->team->title}</a><br />";
 echo "Participant: " . ($team->participant ? "Yes" : "No");
 echo "</p>";
}

Should give you a result like this:

Year: 2011

Team: Team Radioshack

Participant: Yes

Year: 2010

Team: Team Radioshack

Participant: Yes

Year: 2009

Team: Astana

Participant: Yes

  • Like 3
Link to comment
Share on other sites

I know I said before that I didn't think there was a place for repeaters here. But now I take that back.

That's very sincere of you. You have such an open mind when it comes to solving problems. Great work and I think SiNNuT and I and potentially others have some food for thought right now. In my case there were no riders, but Korfball players for one club. It might be interesting to follow their progression throught a career. This would be next to impossible in Textpattern, but I thought about it a lot. Your thoughts should work too. I never even started the project because I was afraid of the potential pitfalls I might run into. But this was before my PW days, so I might give it another go. Thanks again.

  • Like 1
Link to comment
Share on other sites

Thanks Arjen! This is the sort of stuff that PW was designed for, and I think is also the most fun stuff to develop with it. There is almost always a way around any pitfalls.

Please keep us up to date with how your projects go and with any questions you run into along the way.

  • Like 2
Link to comment
Share on other sites

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
 Share

  • Recently Browsing   0 members

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