Help me understand pages & templates

[Andrew Means]

I may be overcomplicating things in my head, but I'm trying to understand a few things about information architecture in PW. Perhaps the best way to get my question answered is by a hypothetical site.

Say I'm building a website for a winery. It has a number of different types of information to display:

• Standard page data (headline, subhead, images, body copy, etc.)
  
• A list of wines that have their own attributes (varietal, vintage, price, description, image)
  
• Each wine has reviews associated with them, which have their own attributes (publication, author, score, link).
  
• Testimonials (testimonial text, author) that need to be randomly displayed on certain pages.
  
• A pagable list of events at the winery (sortable by date, etc.)
  

How would I go about setting this information architecture up in ProcessWire?

[diogo]

The tree for this site could be something like this:

-home

--wines

---wineA

----reviewA1

----reviewA2

---wineB

----reviewB1

----reviewB2

--testimonials

---testimonialA

---testimonialB

--events

---eventA

---eventB

Hope you can take some sense out of it.

Take some time to study the API (have also a loot at the Cheatsheet), go through this small project walkthrough, and have a good look at the default install site. Ask any question here in the forum, I'm sure people will gladly help

[Andrew Means]

Maybe I didn't explain this well enough - that's precisely the tree I was envisioning, but I'm at a loss as to how to create the requisite fields for the wines, events, and reviews, and especially at how to make the reviews relationally bound to their respective wines. When I go to on 'Setup > Fields' I see a list of fields, but these fields only have to do with a page.

Is it that there is only one type of 'thing' that processwire really deals with, and that's pages? And then there are just different formulations of those pages that have different groups of a master list of fields? So if I want to create the ability for my client to add a new wine, I need to add all the 'vintage' and 'varietal' etc. fields to the master 'fields' list, and then create a new template that selects those fields?

[yellowled]

Is it that there is only one type of 'thing' that processwire really deals with, and that's pages? And then there are just different formulations of those pages that have different groups of a master list of fields? So if I want to create the ability for my client to add a new wine, I need to add all the 'vintage' and 'varietal' etc. fields to the master 'fields' list, and then create a new template that selects those fields?

You're right - ultimately, everything in PW is a page. Think of a page as a combination of a template (which controls the way said page is emitted in the frontend) and fields (which control which data said page has access to, although there are ways to access data of fields other pages use as well). (This, of course, is a pretty simplified version of what a page can be in PW.)

For your client to add a new wine, he'd have to create a new page using i.e. the template ”wine” which could (this might be just one of the many ways of implementing this in PW) hold all the fields to store properties of the different kinds of wine. But there are many different types of fields available in PW to make this process maybe much easier than you'd first think. For instance, the varietals could simply be a select box which offers a limited selection of varietals to be selected in the backend.

[Andrew Means]

I think I was getting confused by the nomenclature - there are often things on your average website that aren't strictly 'pages' and it seems odd to conflate everything into the term 'page'. Also the idea of there really only being one Model (page), but a bunch of different Views (templates) is an interesting way to attack the problem of flexible website building... It actually does solve a few problems I was dealing with in my home grown CMS but also raises some interesting questions about traditional information architecture. Interesting...

[diogo]

You will have an idea of how powerfull PW's approach is when you start building your templates. I can give you some simple examples based on that tree:

// you're on the homepage and want to display all the wines:
$wines = $pages->find("template=wine"); // could also be $wines = $pages->get("/wines/")->children;
echo "<div class='wines'>";
foreach($wines as $wine){
  echo "<div class='wine'>";
  echo "<h2>" . $wine->title . "</h2>";
  echo $wine->bodycopy;
  echo "</div>";
}
echo "</div>";

// you're on a wine page and want to display all the reviews:
$reviews = $page->children;
echo "<div class='reviews'>";
foreach($reviews as $review){
  echo "<div class='review'>"
  echo "<h2>" . $review->writer . "</h2>";
  echo $review->bodycopy;
  echo "</div>";
}
echo "</div>";

// display a random testimonial on the homepage:
$testimonial = $pages->get("/testimonials/")->getRandom;
echo "<blockquote>" . $testimonial->quote . "</blockquote>";
echo "<cite>" . $testimonial->author . "</cite>";

// a list of events that take place in the garden of the winery, by descending date:
$events = $pages->find("template=events, place=garden, sort=-date");

//and so on...

edit: made the code a bit more clear, and corrected one variable

[Harmster]

Maybe it has been answerred before but when I'd try to explain what PW is I always say that pages are basicly collections of 1 type of stuff... And all those collections can be used from templates... Users is a collection of users and those users can be in a group which is part of the collection groups... But in PW it is called Pages.

So basicly in your example you would have the following pages (collections)

-Wines

-Reviews

-Testomonials

So you make a few templates, a template for Wine, Reviews and testominials. You add some fields to each template

-Wine

--Title

--Verietal(text)

--price(float)

etc etc

and you make children in this pages(collection)

1 for each wine!

and u add some review pages(a few pages into the collection) to each wine with a review template and u get something simulair to the tree diogo mentioned

-home

--wines

---wineA

----reviewA1

----reviewA2

---wineB

----reviewB1

----reviewB2

--testimonials

---testimonialA

---testimonialB

--events

---eventA

---eventB

Not sure if i was completely right but this is how I have things ordered in my head... kind of

[ryan]

there are often things on your average website that aren't strictly 'pages' and it seems odd to conflate everything into the term 'page'. Also the idea of there really only being one Model (page), but a bunch of different Views (templates) is an interesting way to attack the problem of flexible website building... It actually does solve a few problems I was dealing with in my home grown CMS but also raises some interesting questions about traditional information architecture. Interesting...

To the outside world (those accessing your website) everything is a page, accessed by a URL. ProcessWire is just trying to maintain consistency between the outside and the inside. All pages have a consistent set of properties and methods, but a Page derives its actual "type" from its template. So a Wine, a Review and an Event are all different types, while still sharing the common heritage of being a Page. A Page is basically a URL addressable container for data that has a parent and optionally children. But beyond that, everything about the Page's type comes from the template.

Pages in ProcessWire are very similar in concept to nodes in Drupal (from what I understand). But nodes in Drupal are abstracted away from URLs whereas pages in ProcessWire are always connected to a URL. Even if that URL is tied to something you never intend to use as a renderable page on your site (and might not even have a template file), the URL is still a consistent, known way for you to refer to a page from the API, or wherever. A Page's URL is always reflective of its parents, meaning you know where a page physically lives in the tree based on it's URL. ProcessWire embraces the addressing system of the web, both on the front-end and back-end.

[SiNNuT]

I think I was getting confused by the nomenclature - there are often things on your average website that aren't strictly 'pages' and it seems odd to conflate everything into the term 'page'. Also the idea of there really only being one Model (page), but a bunch of different Views (templates) is an interesting way to attack the problem of flexible website building... It actually does solve a few problems I was dealing with in my home grown CMS but also raises some interesting questions about traditional information architecture. Interesting...

ProcessWire doesn't translate real well into the MVC pattern but at some points :

• Model. Represented in PW by a Template. Here you define your datamodel by adding Fields to the template. You can have as many models/templates you like. In PW 'pages' are modelled by the template that you choose when creating a page.
  
• View and Contoller. This is where a Template File come in. ProcessWire doesn't enforce a strict separation of output presentation (the view part) and controller logic. It gives you freedom to set things up to your liking and project needs.
  

We've had discussions before about the slightly misleading nature of the term 'Page', and what it represents in other popular cms tools.

Just think of Pages as data objects or Entities. An entity has one or more named properties (fields available via the page template), each of which can have one or more values. The value(s) a property can have depends on the field type (integer, date, text, page etc.)

+ what Ryan said

[Andrew Means]

Yes, I get it, that makes sense. I think I like it. In my CMS I was dealing with similar issues; I had Nodes, which represented the main structure of the site, and then nodes were assigned node-types. The node-types were called 'Things' which were essentially Models - these were initially represented by an a collections of fields in an associative array, but eventually were stored in the database. Each Thing was basically an abstraction of whatever thing we were dealing with, whether it was a site page, a testimonial, a wine, or a staff member or what-have-you. And the type of thing determined the kind of behavior the node had. Some had many children of the same type, for example a node with the type of 'wines' would be able to create new wines, list the wines it had created, sort wines, etc. And some nodes had a one-to-one relationship; e.g. a node that had been given the node-type of 'site content' was able to edit the content for that page, and create new sub-nodes/pages. Anyway, I digress.

One of the things I can't decide if I like about Processwire is that, since everything is a Page, your client can put *any* type of page as a child of any other page. It's simple, and probably most of the time it's a benefit, and it more simply solves some of the issues I was having regarding disparate content types along the tree structure. I really like the simplicity that that gives, especially dealing with URLs - in my CMS I had big challenges trying to figure out how to write fully semantic URLs.

Overall I like it. It's weird seeing the different ways this system is dealing with the same problems I was having; I'm sure I'll have plenty more questions but it's really good to grasp the deep concepts first.

[netcarver]

One of the things I can't decide if I like about Processwire is that, since everything is a Page, your client can put *any* type of page as a child of any other page.

Actually, you can control the parent-child relationship, restricting children (or parents) to a certain type (or types) of template. If you edit a template you'll see a tab called "Family" (in the English version) and that's where you can setup restrictions on the relationships.

[ryan]

One of the things I can't decide if I like about Processwire is that, since everything is a Page, your client can put *any* type of page as a child of any other page.

You can put restrictions on this too. When you edit a template, there is a tab called 'Family'. From there you can choose what page templates are allowed for family (parents and/or children). A screenshot probably explains is better than me though.

Regarding MVC and what SiNNuT was saying, a good site profile to look at is the Blog Profile which is takes something much more resembling an MVC approach than the basic profile. Though I'm not suggesting that it's a better approach, but rather an alternative one that some way prefer and some may not.

--

Edit: netcarver beat me to it

[Andrew Means]

Awesome! I know it probably sounds like I'm being all wary and stuff but I'm excited about working with this system/framework (and likely contributing modules to it). I like the UI a lot and its unobtrusiveness with regards to the front-end markup. Great work!

[ryan]

Thanks Andrew, we are happy to have you here. Sounds like you have a lot of background in designing and building CMSs, so we are glad to have your expertise here too.

[Andrew Means]

My 'expertise' is kind of outta left-field, as I'm completely self-taught. So there's probably a ton of things I'm accustomed to doing that aren't really good practices, but hopefully I'll bring a different perspective to the table. It does seem like the overarching goals/methodology is similar - that is, to make tools that maximize flexibility and then build more specific things out of those tools, rather than build a different tool for every job. I used to explain Versa to people like a Video Arcade vs. an NES with a bunch of cartridges. The Arcade has a bunch of games (processes) and each have their own self-contained box. Each box is doing different variations of the same thing (adding, editing, displaying, sorting, deleting, etc.). The NES has one box & one screen, with different cartridges that specify the game. Rather than duplicating the processes for each different thing you have, you build core functions that handle all the processes, and that vastly streamlines the work and makes each client's backend completely customizable.

If you're interested Ryan I'd love to give you a rundown of Versa over skype or something - lots of similarities between the two systems, both structurally and from a UI perspective.

[ryan]

Sounds good Andrew, Thanks-- I'd enjoy getting a look sometime.