Unique attributes per category - ideas on implementation?
I am wondering if anyone has suggestions on how to implement the following. (such as, if I should be able to do this with default components and learning how to customize, or it will require a custom component or using hooks or whatever; I don't think I saw any plugins related to this)
Basically, each record (let's say it's a "product") belongs to a category. However, each category has associated product metadata/attributes, which may vary in their type (text, selection, multi-select, boolean) and rules (required or not, validation). For example, something in the "car" category might have:
fuel (electric or gas)
odometer
condition (new/used/parts only)
Whereas a "phone" category would associate things like:
screen size
storage size
carrier restrictions
I am thinking in the worst case, I can use the "wizard" flop, and then set up the product entry form to be keyed to a type based on the last category selected before entering the product form. Maybe that's best, and too difficult to make it work all on one page... I figured I'd ask though in case anyone has ideas or has implemented something like this. Maybe it's a lot simpler than I'm thinking it will be. 🙂
I still have to think of how to store this database-side. (whether it will be relational, or store an attributes JSON column... depends on search requirements, but also performance... I am assuming I'll end up caching the pages, so it doesn't matter too much to flatten it in the DB...) My question is more about getting the front end to work with this varying set of fields based on category selected.
4 Replies
Just bumping this to see if anyone has any ideas. I'm pretty sure I will have it so that the form is entered with the category already known. But still curious how difficult it would be to swap out sets of attribute/metadata inputs on the form itself if the user changes the category, for example.
Have done something similar with a custom form builder.
Use enums to determine the detail, and logic from those to determine which fields appear.
On a database level, several fields are fixed as columns, and then everything too disparate for single columns is stored in JSON
That's a really nice setup, thanks for sharing! Definitely inspires confidence that what I want will be doable, for sure. And yeah that's a good approach to use a mix of columns and JSON to help normalize a bit without going nuts.