Site Organization

[rick]

Howdy all,

I'm tryin' to wrap my head around the best way to organize a site and hope y'all can offer some clarification.

I have a large number of contractors, approximately 4000.

I have a large number of contractor companies, approximately 10-20.

Each contractor company has a variable number of current job sites working.

Each contractor company has a variable number of specialities, such as electrical, plumbing, etc. Not all apply to each company.

I need some means to assign a contractor to one or more contractor companies, and to one or more job sites, and to one or more specialities.

An organizational option I have thought about is as follows:

Contractors
-- Contractor Companies
-- -- Job Sites
-- -- -- Specialities

So I need to dynamically create each of these pages, ie, add a new job site and assign specialities to a company, then assign one or more contractors. I am thinking of process modules to handle this procedure, then create the module interface to display results on the front end.

I hope that I have explained this well as I've managed to maneuver my brain into a fog.

 

 

[Robin S]

As a general rule, I find it preferable to avoid relying on parent-child structures and use Page Reference connections instead. I think it's more flexible and future-proof that way.

So rather than nesting those things I would create separate branches for them and then connect Job Sites and and Specialities with Contractors using Page Reference fields (in conjunction with Connect Page Fields). I'd use Lister Pro instances to make it easy for editors to find whatever page they are looking for.

[Jonathan Lahijani]

• /contactors/ (contractors.php)
  • bob smith (contractor.php)
  • ...
• /companies/ (companies.php)
  • acme corp (company.php)
  • ...
• /jobs/ (jobs.php)
  • 123 main street (job.php)
  • ...
• /specialities/ (specialties.php)
  • electrical (specialty.php)
  • plumbing
  • welding
  • ...

- create a page field (asm) called 'contractors'; assign it to 'company' template (as well as the 'job' template? not sure if that's what you meant)
- create a page field (asm) called 'specialties'; assign it to the 'contractor' template
- create a page field (single select) called 'contractor'; assign it to the 'job' template

I'm not sure if you also need 'specialities' on your contractor template, but you did mention that as well.

The approach I outlined is the collection-y way of doing it, like a traditional webapp framework.

[Jonathan Lahijani]

I'm hoping my example made sense in the context that you explained it.  I'm not sure if by 'contactors' you mean actual people.

[rick]

Thanks @Robin S and @Jonathan Lahijani.

I was thinking about page references, but posted the hierarchy as a simple way to show the relationship. So Robin, I agree completely, and prefer the future-proof methods as well. Jonathan listed out the organization that clears some of the brain fog. Haha. And yes, contractors are actual people.

Thank you both for your insight!

[szabesz]

12 hours ago, rick said:

the hierarchy as a simple way to show the relationship

I think it is always worth treating data modeling in ProcessWire as if it was an Object Relational Database out of the box. Meaning: think abstract first  You can even implement your code thinking in OOP if you want to.