table of product features

[icietla]

Hello,

I'm working on a product catalog (not an e-commerce website). 

For the product template, I'd like to fill a table of features (the rows) with 3 cols:

- the name of the feature;

- predefined values

- a textfield for a custom value (if we don't want to create a new predefined value)

See the attached file (an exemple from a Prestashop site, but I just want to manage a catalog and I like to work with PW!!!  )

With a repeater or the profield "Table" I can't have this result. 

May be I have to create a specific field type for this use?

Have you any idea?

[dragan]

I guess that should be doable with inputfield dependencies: https://processwire.com/api/selectors/inputfield-dependencies/

[icietla]

Thanks, I've seen your link, it appears it could be a useful way to follow!

I will try with this and I'll let you know.

[Robin S]

For something like this you can use normal fields (i.e. page/options select and text fields), and set the widths of the inputfields so they appear in row groups. If you want a single heading across both inputfields something I have done in the past is: create a fieldset, place the grouped fields inside the fieldset, use AdminCustomFiles to hide the labels of fields inside the fieldset.

[icietla]

Hello Robin,

thanks for your answer. What make it difficult is to let my client easily add features without creating a new field for this.

I think about a commun and simple solution to create and add features, just creating pages with specific templates:

And a repeater for the product template with 3 fields (at 33% to make columns):

- a page field for feature type,

- a page field for feature predefined values

- a textfield for customized value with conditional visibility.

We don't have a table but we can add any features and values.

The problem with this solution: at this state, all values will be displayed in the 2nd input field. 

Can we display in the second page field only values according to the first page field (types)? (like in some forms)

An other simpler solution is to show only the 2nd page field to directly add features values. But il there is a lot of values, showing all possibilities in a select field without the feature type in a long list will not be clear. 

Any idea for a simple feature management solution?

[Robin S]

Can we display in the second page field only values according to the first page field (types)? (like in some forms)

Good news: you can have dependent selects

Bad news: it has been said that dependent selects do not work inside repeater fields

I've never tried them inside repeaters myself. I say give it a go, particularly if you are using PW 3.x because repeaters have had some upgrades there. If it's still a no-go maybe a PageTable could substitute?

[icietla]

I will give up the idea of "customized values", we'll create new pages for a new feature value.

And so, I can use a simple page select multiple field. I have tried the Ryan "Select Multiple Transfer" and it's all right!

I've add {parent.title} : {title} for the field' label to display also the feature's type (like 'Age' in my exemple).

May be to exactly match with my initial idea of feature table with optional custom value, it need to develop a module to add a new field type like "FeatureTable".

[Jan Romero]

I think Profield Table is still your best bet for this functionality. In order to conditionally disable the third row you would inject a bit of jQuery into the edit page.

Per ejemplo:

$('#wrap_Inputfield_features input').on("change", function() {

	if ($(this).val() == '') {
		$(this).parent().next().css('background', '#f0a');
		$(this).parent().next().children('input').prop('disabled', false);
	} else {
		$(this).parent().next().css('background', '#ff0');
		$(this).parent().next().children('input').prop('disabled', true);
	}
});

[icietla]

Thanks Jan,

do you think the best way to add some JQuery into the edit page is to use the Admin Custom Files module?

Thinking about tables, it could be interesting to have an input field table that already creates rows in the admin according to existing pages of a given template or parent (in my example, the features_type template). The first column would be a label with the page title (same display as the Textareas pro field for the left colums).

[Ivan Gretsky]

This is a great question I was going to ask myself one of these days. So thank you, icietla!

I can think of another option (that has been rejected by you straight away though) for that: using repeaters with field dependencies. I mean 1 page field to select a feature, another one (initially hidden) to display available options for that feature, and a text field for custom options. You can even put a link there to create options in place. Repeaters are not so nice as a table from the GUI point of view, but they will do the job.

This way it is not so easy to make a predefined list of features.

[Jan Romero]

do you think the best way to add some JQuery into the edit page is to use the Admin Custom Files module?

I don’t see why not, although I have no experience with the Custom Files module. You could just hook into ProcessPageEdit from your admin.php. Here is a more complete example:

$wire->addHookAfter('ProcessPageEdit::execute', function(HookEvent $event) {
	$tableField = 'product_features';
	$changeColumn = 'feature_value';
	$disableColumn = 'custom_value';

	$event->return .= ("<script>
		$(document).ready(function() {
			$('#wrap_Inputfield_{$tableField} input[name$=_{$changeColumn}]').on('change', disable_my_field);
			
			function disable_my_field() {
				//probably not the best way of finding our target field…
				var disableThis = $(this).parent().parent().find(':input[name$=_{$disableColumn}]');
				
				if ($(this).val() == '') {
					disableThis.prop('disabled', false);
					disableThis.parent().css('background', '#f0a'); //color just for better visibility
				} else {
					disableThis.prop('disabled', true);
					disableThis.val(''); //clear field
					disableThis.parent().css('background', '#ff0');
				}
			};
			
			//call the function once to affect existing rows
			//can’t get this to work for some reason
			disable_my_field.call($('#wrap_Inputfield_{$tableField} input[name$=_{$changeColumn}]'));
		});
	</script>");
});

It’s not quite there yet, but it works pretty well. Seems quite useful actually. I might use this myself sometime. You can of course use the same principle to pre-select options based on another column.

Thinking about tables, it could be interesting to have an input field table that already creates rows in the admin according to existing pages of a given template or parent (in my example, the features_type template). The first column would be a label with the page title (same display as the Textareas pro field for the left colums).

You may want to look into this thread: https://processwire.com/talk/topic/2331-doing-additional-logic-after-saving-a-new-page/. It’s a bit old, though.

[icietla]

Hello,
 
@Ivan
But as said Robin, it seems that repeaters don't allow field dependancies to find values for a selected feature.
 

" Bad news: it has been said that dependent selects do not work inside repeater fields   "

@Jan

Thanks for your advises for changing the admin edit page. I'm not used to do that but it seems very powerful! I will try this!

[Robin S]

I think Profield Table is still your best bet for this functionality.

I don't see how Table can help here, because it doesn't allow for dependent selects (i.e. selects that change options/pages based on the value of another select in the same row). And it doesn't include SelectMultipleTransfer as one of the available inputfields.

But as said Robin, it seems that repeaters don't allow field dependancies to find values for a selected feature.

Did you investigate to see if a PageTable (hereafter 'PT') could work for you? Dependent selects work here, you can use "show if" settings to control field visibility, and you can choose the PT template fields you want to see in the table. So it seems like it would be a good solution.

If you define a parent page for the PT pages and set a dedicated template for that parent page you can then use the "Name format for children" option to skip the page name step when adding new PT items. See the Setup Page Name module for more name format options. As the for the title field for the PT items: either set it non-global and remove it from the PT template, or use an 'added' hook to set the title automatically and optionally a 'saveReady' hook if you want to form the title from field values in the PT page. I can elaborate on this if needed.