I am using Ubercart for products on a Drupal site. I want to extend this product to show a wide range if different information on products. One of the bits of info I want to show, is "specifications".
Take this product as an example. It has various categories of specs, e.g:
Attachment and Capacities
General Specifications
Function and Size
But each of those categories, has actual values underneath them. E.g. Under "attachment and capacities" you have:
Citrus press:Yes
Dough tool:Yes
Mini bowl :Yes
Etc
When I create a new product, I want to be able to add infinite amounts of specifications, that fall under a group.
The best way I have found to do this is using Inline Entities. But this is very slow. Is there no better "field type" I could use to demonstrate this relationship? I.e. one where I can infinitely add categories of values to a specific node?
You can use Product Specification module to achieve the same.
This module allows you to attach product specification data to any
entity in Drupal 7. Mostly we can use this module to store product
specifications on product display page.
Related
I'm working on a classified ads site with 12 categories. E.g. category vehicles has items cars, bikes, Commercial Vehicles and spare parts. The following is a flow diagram for posting an ad:
I need to show the specification in the Form Filled section of the above image to the users in dropdown lists in the form when they are posting an advertisement. The car specification will be its color,engine,fuel type.
The ERD is below :
How should this issue be tackled, what are the best practices and is the current design going along the right lines?
On the whole this looks ok. Here are some observations:
likes.iker_id should point at users.id? Just trying to understand your model to start.
I would probably change the pics table to be one pic per row and then add an ordinal for ordering.
One question here is how you intend to look at your graph model. As it is, you might have a graph that could be traversed easily to a depth, a couple deep. I assume you are doing this to recommend ads. If so, I think this is sufficient. If not it would be good to further discuss which rdbms you are targetting.
Hope this helps:
In a simplified case, you will need some extra tables.
So, you are trying to be able to have different specifications for different items in your categories? Or, in other words, it is like having different attributes for different types of products in an e-commerce website.
If that the problem you are tackling, then you should look into the Entity–Attribute–Value (EAV) model that is how the problem is solved. By the way, one of the most popular open source e-commerce engines uses it as well.
i agree look at EAV models...
for some other tables, you have many normalization issues - for example:
you should have a separate address table (not part of the ad)
you should have a picture table (and link those to the ads with another table)
you should have a person table - and link that to the ad as 'owner'
the idea of 'favorite' should also be in this person->ad relationship table as a role or type column
I'am trying to find an efficient approach or algorithm to help me address the problem described below.
Let's say we have a database containing a very large collection of products. Each product has a large set of attributes, although these attributes could be shared among product. In additon, product are organized into multiple hierarchical categories.
An example: Home -> Kitchen -> dishwashers -> GE Electric Dishwasher Model blablabla.
I would like to present to a user browsing our products a list of possible filters he could use. To illustrate it think about Amazon product filters on the side of the page: If products have a "price" attribute, then they show a slider with the lower price and the highest price as extremities. If the attribute is "brand", they have a list of all the brand for all children of a selected category. Categories and attributes are two separate concepts in our design.
My problem is all computing these filters takes time because we have a very large collection of products with dozens of attributes. Is there a particular way to perform this filtering? I was thinking about computing all filters at each level before hand but since a user may apply the filter at a higher category and keep navigating down into more specific categories, the latter categories would need to be recomputed/updated anyway.
What we have tried: for each product in a selected category we compute the intersection of attributes and create filters based on it. results are not cached since filters propagate from parents to children categories when applied.
PS: the database I am using is SQL server 2012. Let me know if more information is needed to better answer/understand my question. Also if you think of more appropriate tags for this question, please feel free to update it.
I have a strange requirement in Solr.
The business model is like for each store in state (say victoria), we have different sales catalog (like Richmond, Brunswick etc) which in turn act as fulfillment centers on their own.
so my url of storeId- vic and catalogId-Richmond will retrieve me catalogues with richmond's store.
Now the requirement is I need to filter out the products based on the inventory for each of these sales catalogues.
I constructed a TI table which has the following structure
catentry_id -------- QUANTITY_RICFUL-------------QUANTITY_BrunFUL
1234-------------------0------------------------------------20
I had incorporate the changes in solr query to add these columns in the final result too.
But I do not know how to filter out the products in the front end during catalogue navigation or during search.
Any help would be much appreciated!!!
So basically you want to tie the returned catalog entries in a list with inventory? For instance, when they click on a category you do not want to display products with no inventory?
This would be a customization you can either do at the Solr Level or at the JSP level. You should probably track inventory in commerce (import it) into a field Solr can key off of and then only return items with the flag set to greater than zero. I am not sure if you need actual inventory or just a boolean. Are you using a single fulfillment center or multiple ones? Multiple gets a bit trickier and it would require them to log in most likely but then fulfillment would be addressed by the ship to address.
If the store is set up with ATP inventory then you should just get this for free, as products not in stock will simply not be displayed. Check out this page in the infocenter - http://publib.boulder.ibm.com/infocenter/wchelp/v6r0m0/index.jsp?topic=%2Fcom.ibm.commerce.user.doc%2Fconcepts%2Fcosatpatpandnonatp.htm
I am not sure what you are trying to ask here but it seems you are trying to display a Quantity dropdown or display an Quantity field under each product on a search page which to me makes no sense from a UI perspective. Also keep in mind if you have integrated with a 3rd party inventory model that runs every few mins/hours etc. How often do you plan to run indexing etc?
I would rather leave such complexity to a Prodcut Detail page. If you do require to show an Quantity field on the search page I would rather prefer displaying a QuickView popup/modal that displays the color/size attributes with the quantity dropdown etc and enable a user to add an item to his/her shopping cart.
I'm using Ubercart 3.x, Drupal7. Can anybody tell me how can I create a form for searching in products with price in specified interval? I.e. user should fill this form with minimum price in the interval and maximum price and after posting form he will see all suiting products.
I think you should be able to create a view to do exactly this. if you haven't already done so, install the views module. create a new view, filer by type of product, and add two exposed filers on the price field, one greater than and one less than.
When you publish your view, the user will see a form with two fields, and can search for products in the specified price range.
Hope this helps. If you haven't used views before, it's worth perusing the documentation first.
James
First post, please be kind.
NOTE: I have reviewed entry #20856 (how to implement tagging) but feel this is different due to the fact that the tags method I'm considering is organization specific in my app. I’m hoping someone can confirm the direction I’m going or point out some other options.
(background) We are building a web application that gives different organizations visibility to their inventory in different locations. The database stores users, organizations, sites, and items and there are links from sites and items to organizations that allow us to determine which items / sites to show to which users (based on their organization).
It is common for two (or more) organizations to want to use the portal to check on the stock status of (for example) Widget A in the Los Angeles Warehouse. That part is fine. However, the different organizations also track unique information about Widget A. For example, Org 1 wants to track the color, volume, and primary vendor for each item. Org 2 wants to track Color, Stock Type, Inventory Cycle, Buyer Code for each item. I want to avoid a situation where I have to have a table loaded with all these possible fields and then figure out which organizations use which fields.
I’m considering using something along the lines of tags, but adding a tag category, and having the tag category be defined at the Org level. So, the basic table structure would be something like:
Table: OrgTagCategory
Fields: OrgId, TagCategoryId, CategoryTitle
Table: OrgTag
Fields: OrgId, TagCategoryId, TagId, TagTitle
Table: OrgItemTag
Fields: OrgId, ItemId, TagId
Then, when the user logged in the main dashboard the grid would include their appropriate item fields as columns in the grid. So, from above example, Org 1 would see Item#, Description (would be shown for all), color, volume, and primary vendor. Org 2 would be shown Item#, Description, Color, Stock Type, Inventory Cycle, Buyer Code.
Am I overthinking this or is there a simpler method of doing this that I’m missing? All thoughts / feedback sincerely appreciated.
That should be no problem, but you're storing the OrgId redundantly. Also it seems like there could be some overlap (probably a lot of overlap, realistically) between tags and orgs.
Here's how I'd do it:
Table: OrgTag
Fields: OrgId, TagId
Table: Tag
Fields: TagId, TagTitle
Table: ItemTag
Fields: ItemId, TagId
This way each org is associated with the tags it's interested in, but you don't have redundant tags. A given tag that's used by multiple orgs just gets a bunch of rows in OrgTag, instead of multiple rows in Tag with the same TagTitle.
You'd only need a table OrgTagCategory if there were multiple tag categories per org. But you haven't described this extra association as a requirement.
Based on your description I sketched a simplified model and combined it with the observation pattern. This should enable you to track various item properties and user preferences for viewing them. Admittedly, the Preference table may grow large, but data has to be stored somewhere anyway, and you may retrieve it using sql, which simplifies the business layer.
- Organization and person are types of users. User table has columns common to all users, while Organization and Person tables have columns specific to each one.
- A stock item (widget class) can be found at several sites (warehouses); a site stores many items.
- One item belongs to one user; a user can own many items.
- Measurement and trait are types of observations. Measurement is a numeric observation, like height. Trait is a descriptive observation, like color.
- An observation is of a specific type (height, weight, color), there can be many observations of the same type.
- One item (widget class) can have many observations, an observation relates to one item only.
- A user can prefer to display many observations; an observation may be preferred (to display) by many users.
UPDATE
We could simplify user's subscription to item details (observations) by tagging observation type, for example height, weight, width would be tagged with: all, dimensions, physical. Some other tags would be: accounting_interest, tracking_specific, etc. A user would then subscribe to tags only. Tags (could) form a hierarchy with ALL at the top.
- One observation type (height, weight, color) can have many tags, one tag belongs to many observation types.
- Each tag may have a parent tag forming a hierarchy.
- A user stores preferences for a set of tags that she usually monitors.
UPDATE 2
Now we can sort out who is who and who owns what. In this modification a user (now a person) can work for more than one organization (having several part-time jobs or contracts). An item belongs to a organization now. A logged-in user can see all items from all organization that she works for.
My first quick thot on this would be that - if this is just limited to 'showing' particular fields to particular Orgs on Dashboard then it is better to handle it on the App side. If there's any other usage of 'tagging' then pls clarify.
Here's a simple approach -
You can store a field [OrgDashboardFields] in the Org master table or the OrgItem table. This will be a comma (',') separated list of fields to be shown on the dashboard. At run-time fetch the [OrgDashboardFields] field and parse the comma separated list in the app and make the Dashboard Grid behave accordingly.
Or, if there's a dynamic-query framework then based on the [OrgDashboardFields] field you can create a dynamic SQL-query and get the desired result which is purely Org specific.