Populate List Field Editor From Multiple Tables

Hi,

Yes, you could probably do this, but it would be a fairly complex query.

Can you give an example of a situation where you would need to do that?

Hi Jason,
Surely. Lets say there's a music equipment store... Each product type would have its' own list page editor (electric guitars, acoustic guitars, electric bass, acoustic bass, etc...).

For the home page, lets say there is a "Featured Gear" area that would display a set number of selected products (for example a set quantity displayed static or X amount allowed for a carousel type auto scrolling effect).

I was thinking about using a single record editor labeled as Site Controls to allow controls over certain global areas of the site, one of which being for the Featured Gear area on the home page, and setting up a multi value list field editor that would pull in all of the product listings to choose from as check box style.

Thank you.

Hi,

Okay, I see where you're going. I like the idea of having a "Site Controls" section.

One suggestion that I would make that might make this a little easier for you would be to have 1 section for products. In that section, you can have a list of "product types" (ie, electric guitars, acoustic guitars, etc). You then select a product type for each product. This would allow you to just have to worry about pulling in information from a single section. You would also have a central place for data entry and would be able to use a single listPage / detailPage set to show all products.

Hope this helps

I totally agree that would be muuuch easier to work with! In that case, for this situation, the list would be huge. We were sectioning off the different product lines into their own respective list editors to be easier on the clients end to work with and sort through - at their request.

Hi,

The problem here is that you would need to have a single field that would be unique across all the tables that are being queried. You would also have to have a way of determining which table an individual record came from. Although this is probably possible, the complexity would most likely outweigh any benefits.

If they're worried that a single list would be too large, you can easily set up a search in the CMS to allow them to filter their list by product type. If they already have things in multiple tables, it would also be fairly easy to create a script that would merge them into 1. This is definitely going to be the best approach.

Hope this helps

Hi,
I am in total agreement. I can foresee a lot of programming hours to handle something that complex. Hopefully I can push them in the other direction, and maybe explaining the extra cost may have them change their mind :)

Thanks, Jason! Happy Holidays!