Jump to content

table of product features


icietla
 Share

Recommended Posts

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?

post-1990-0-39917700-1464962435_thumb.pn

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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:

post-1990-0-94629700-1465199060_thumb.pn

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.

post-1990-0-33168600-1465199070_thumb.pn

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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!

post-1990-0-42059800-1465218401_thumb.pn

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".

Link to comment
Share on other sites

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);
	}
});
Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

Link to comment
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
 Share

×
×
  • Create New...