select or not select - that is the question

[valan]

Hi!

I'm trying to find optimal solution for "cars database" site I'm currently developing.

Background:

Each car has variable but limited list of attributes: model, length, number of seats, color, etc - total more than 50 attributes that average consumer is interested to know. Each attribute has value, e.g. model=BMW 3er 318i, length=5.5m, number of seats=5, color=black.

These attributes and their values are added in the repeater field of car page, where attributes are selected from available limited list (page select field type) while values are entered manually (text field). Repeater is used because number of required attributes vary from car to car.

Problem:

Depending on attribute, some value fields need to be "selectable" and some not. For example, if attribute is "color", then available through select values should be "black" and "white". Other value field should not be "selectable", e.g. "length" attribute could have any decimal value.

So far, I haven't found an elegant way to make such dependency and value selection (only when it is needed) within repeater. 

Do you know an elegant way how to make PW work as I need? I'd like to make life of content manager (person who enters cars data into the db) a bit easier. ) Thanks for help!

[Wanze]

Hi valan,

Why not making your attributes fields of the car template? Then the editor just fills out the ones needed for the actual car.

model, length, number of seats, color etc. - they all hold a single value.

For attributes that can hold multiple values, you can still use repeaters.

This also solves the 'select' questions, if I didn't misunderstand your question.

To make life easier for the editor, I'd probably group the fields with InputfFieldSetTabs.

[valan]

Hi Wanze!

Thanks for suggestion.

(1) Repeater is used because number of required attributes vary from car to car. E.g. there is no reason to keep 50+ attributes in a car page where only 10 attributes are used.

(2) Repeater is a great way to write short code that renders attributes and values in foreach cycle. With fields, developer needs to write 50+ lines (render each field). Also if you use repeater, you don't worry if attribute name has changed. If you use fields, you need to update code.

E.g. fields are OK, but not so elegant in my mind.

[diogo]

But isn't it more difficult for the editor to remember to add all the necessary repeater fileds, then to browse all the fields and fill the ones that are needed?

[Wanze]

Hi valan,

I see your point but I still think fields are the way to go.

There are for certain some fields that are more often used, so you could group them together.

Don't worry about the cars that do just hold a bunch of attributes, Pw scales well.

You have more overhead with repeaters, because each repeater item is stored as page in ProcessWire.

So with a car that has 50 attributes as repeater-items, you end up with 51 pages (1 car page + 50 repeater pages).

You don't need to write 50+ lines of code, you can also loop through the fields of a page:

foreach ($page->fields as $f) {
  // Maybe check for the value based on the type of field (select, page)...
  // if ($f->type == 'FieldtypeXY) ...
  $value = $page->get($f->name);
  if ($value) {
    echo $f->label . ' has value: ' . $value;
  }
}

[valan]

Hi Wanze!

I should probably add from the very beginning that attribute pages (ones, that editor selects within each repeater item) have few other fields, particularly attribute category and attribute measure. For example, "length" attribute has "carcass" category and "cm" measure. So later during rendering attributes are grouped by category and values have measures.

In this case I have to add 50*3 attribute fields (name, category, measure) + 50 value fields into the page... it is too much...

Nevertheless, thanks for idea with foreach ($page->fields...) - quite useful PW feature that I've never used before!

I guess that my question touches more fundamental things in PW. As far as I understand, currently PW pages are "field-static". I believe that introduction of a "dependable field" (field that PW dynamically substitutes based on "parent" field value within a page, using rules predefined by developer) in PW pages could attract more sophisticated projects.

[valan]

Hi diogo! Good question. I've mentioned in my reply to Wanze that attribute pages (ones, that editor selects within each repeater item) have few other fields, particularly attribute category and attribute measure. So editor doesn't fill category and measure in each page. It can be done in attribute page only. E.g. I would agree with you and Wanze that use of fields instead of repeater is probably more optimal in cases when there are no additional fields associated with attribute. But in my case - not sure... too many fields in a page.