Closed (fixed)
Project:
Commerce Core
Version:
7.x-1.x-dev
Component:
Views integration
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
18 Jan 2011 at 16:59 UTC
Updated:
3 Jan 2014 at 02:58 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
rszrama commentedThe use case was building a View to display the most viewed products. Because the view count is associated with the node displaying products, this has to be a Node View instead of a Commerce Product View. However, a module defining this View won't know what product types on the website reference products to include only those node types in the View. Additionally, someone might create a new node type and not know that they need to come update the filter settings on this View. : )
Comment #2
bojanz commentedSounds useful :)
Comment #3
bojanz commentedSomebody stole march from me. Or drupal.org is lying that it's april 1st.
In any case:
http://drupalcode.org/sandbox/bojanz/1097750.git/commitdiff/refs/heads/1...
Comment #4
rszrama commentedHmm, the idea was actually to have more of a boolean filter where it's either filter by "all product types that have a product reference field" or "all product types that don't have a product reference field." The idea is that this filter should work regardless of the actual name of the corresponding node types, so it could be used to create a generic Catalog View that doesn't have to presuppose the name of any particular node type.
Granted, this is functionally equivalent to adding a required relationship through the product reference field, so I guess the idea was really just a simplicity thing.
Comment #5
rszrama commentedAnd just to clarify - the filter itself would function behind the scenes as a regular node type filter, so you'd still have to supply the appropriate node type names... just the customer shouldn't have to specify them all in the settings form for the filter. That's where it should appear as a boolean decision (through radios I'm guessing, actually).
Comment #6
vasikehere is patch for this filter
Added the "Product Display type" filter from the "Commerce Kickstart Content UI" module with some naming changes
'product_display_type' instead of ''product_display' to avoid some conflicts at least till the filter will be romved from Kickstart module.
and
'commerce_product_reference_handler_filter_product_type' instead of 'views_handler_filter_product_type', use the Drupal commerce naming "convention".
With this, Commerce Kickstart requires some changes: some views to be rebuilt, the "old" filter removed.
Comment #7
vasikereworked the previous patch.
Created 2 views filters
- Is Product Display? : Whether or not the content is one of product displays.
- Product Displays Content types: Select Content types which are Product Display
Comment #8
bojanz commentedSo, we definitely need those two filters for Kickstart v2.
The implementation is insanely simple, thanks to the commerce_product_reference_node_types() function we added previously.
Perhaps commerce_product_reference_handler_filter_is_product_display should be named commerce_product_reference_handler_filter_node_type_is_product_display (clearer, but insanely long)
Letting Ryan bikeshed the class names / labels, if he wants to :)
Comment #9
bojanz commentedTagging.
Comment #10
rszrama commentedGreat start, vasike. Yes, I did change the names to include "node" in the class name, and I also changed the "is a product display" filter to extend views_handler_filter_boolean_operator instead of views_handler_filter_in_operator. This actually reduced its size and avoided having an "in" filter that didn't actually have options.
Commit: http://drupalcode.org/project/commerce.git/commitdiff/39ae75d