Jump to content
valan

select or not select - that is the question

Recommended Posts

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!

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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;
  }
}
  • Like 4

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
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

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By picarica
      so i made some options in t he field type, and i want to check if selected title is that output this is my sample code
      if($media->r_soc == 'facebook') { $soc = 'facebook'; } elseif($media->r_soc == 'twitter') { $soc = 'twitter'; } i just basically want to check if the user in CMS selected option facebokk and then outpit it into variable which is later outputted into fa icon, oh and also this is all in repeat field
      foreach($ikonky as $media) { so thats why its $media, but as of now it outputs blank state, not sure why,
      it doesnt outpit anything none of the check goes throught these are options i have in the field
      1=facebook 2=twitter 3=instagram 4=youtube 5=github 6=linkedin  
    • By gerritvanaaken
      My client could save some time if she could select multiple pages at once. Of yourse, we are using the standard page selector in multi-tree mode, but she has to select one page after another. Each time she has to open the site tree again and open the required subtree, finding the page she wants to select.
      Would be cool to let the tree open after selecting a page, so she could select multiple pages in one "tree session". Understand what I mean? Anybody any solution to this?
      Alternatively, maybe the site tree could keep its state with all the subtrees open, when you are re-open it again.
    • By louisstephens
      Going through my long quest to get better with ajax and utilizing the api, I have hit yet another roadblock. I currently have a form with an image field (thanks to flydev for getting that sorted), "title" text input, and a select field set to multiple. In my ajax call, I added in:
      tags = $("#select-tags").val(); form_data.append('tags', tags); $.ajax({ type: 'POST', data: form_data, contentType: false, processData: false, url: '/ajax/upload-preview/', success: function(data) { console.log("Woo"); }, error: function(xhr, ajaxOptions, thrownError) { alert(xhr.responseText); } }); And in the ajax template: 
      $tags = $sanitizer->text($_POST['tags']); $image = $sanitizer->text($_POST['image']); $p = new Page(); $p->template = "preview"; $p->parent = $pages->get("/previews/"); $p->name = $title; $p->title = $title; $p->tags = $tags; $p->save(); If I select a "tag" from the select input and submit, it does indeed add it to the Page Reference field in the backend. However, this does not work with an array being passed to it of multiple options.

      So it does appear that my ajax call is trying to submit multiple options, but I am really just unsure how to get these two added in. I saw in other forums posts of add($page) and even add(array()). Do I need to handle this js array differently or do  I need to foreach through the $tags to add it like:
      foreach($tags as $tag) { $p->tags->add($tag); $p->save(); } I tried this approach, but apparently I am still missing something.
       
      Edit:
      I was doing some tweaking, and I know I can split the js array out like:
      for (i = 0, len = tags.length; i < len; i++) { console.log(tags[i]); } However, I am not sure then how to handle the POST in php if I were to split it out.
    • By sambadave
      Hi everyone, here's the problem I'm trying to solve.
      I have a config area in my PW admin that is locked down for admin use. I use pages to store a bunch of settings that I'll use for my clients website. It's mostly used for visual things like colours and theming. This list could be tiny or large, depending on the sites requirements, but its great because I can store any information I want to. So the page tree could look something like this:
      ADMIN SETUP
      Home Config Aesthetics Colours Red Field: Custom Label - "Red" Field: Class name - "theme--red' Green Field: Custom Label - "Green" Field: Class name - "theme--green' Blue Field: Custom Label - "Blue" Field: Class name - "theme--blue' etc... Sizes Small Field: Custom Label - "Small" Field: Class name - "sm' Medium Field: Custom Label - "Medium" Field: Class name - "md Large Field: Custom Label - "Medium" Field: Class name - "lg" etc... Icons Target Field: Custom Label - "Hands shaking Icon" Field: Icon SVG - "[svg code]' Target Field: Custom Label - "Target icon" Field: Icon SVG - "[svg code]' Success Field: Custom Label - "Happy face icon" Field: Icon SVG - "[svg code]' etc... HOW I USE THIS
      I'm then able to set up page reference fields for colour, size and icons. I'll use these fields on particular pages so that my clients can select a particular colour, size or icon, or anything really. Currently, with the page reference field I can create a custom label for the options. So for something like colour I can label the field "Theme" and present a list of colours like "Red, "Green" and "Blue" using the custom page label label format of the colours page.
      This of course means that I can use this to do some lovely presentation on the front end of the site. With a colour selected I'll then be able to use the page reference to get the class name for that colour theme so that I can update the page's look and feel. So in my markup I'd end up with "theme--red" or "theme--green" etc.
      THE PROBLEM
      I have this all working which is great and it's really flexible for the client which they love. However, I'd love to be able to make things more visual for the client.
      Is there a way to be able to output more than just text in the page reference field? I might have a bunch of different blue colours, so instead of a list like so:
      Navy Blue Deep Blue Bright Blue Sea Blue ... it would be great to be able to output actual colour swatches, which is a lot mor visual for the client.
      Taking the icon selector, I would ideally like to show the actual svg that I've stored against that icon as a selectable image instead of seeing text options like:
      Hands shaking icon Target icon Happy face icon Just a couple of scenarios here, but as you can see there could be any number of reasons to display a more visual method of selection.
      ANY SOLUTIONS?
      I've looked at modules like FieldtypeColorPicker which could help in solving the colour issue, but it doesn't allow me to select a colour and then use a particular class name assigned to it the way I describe above.
      Considering the other use cases I mention above, does anyone know if anything exists already that would help me to create custom presentaion for page reference lists, or if there's anything planned?
      Thank you in advance for anyone who's read this far and has any words of wisdom!
      Dave
       
    • By louisstephens
      So I was tinkering around with the "select fields" field type and added it to a repeater. My thoughts were I could have a user select a field (textarea, text, etc etc) that I defined and give it a name (another field in the repeater) and create their own form on the page. To be honest, I am now a little lost with rendering the form and mailing the results as potentially the form will be unique and custom every time.  The only way I know to handle the output is by going about it this way:
      $forms = $page->form_select_fields; foreach($forms as $form) { if($form->name === "form_input") { //output input with custom name } elseif($form->name === "form_textarea") { //output input with custom name } } Is there a better way to go about rendering the elements from the repeater? As far as the custom sending goes, I am really at a loss since it would be pretty dynamic. Has anyone used this type of approach, and if so, how did you handle this without going insane?
×
×
  • Create New...