Answered Populating a drop-down TV with another TVs output, to group resources

Hi,

I'm building a site for an arts organisation, primarily to act as a project archive of their exhibitions and events. Their work is varied and projects are just as likely to consist of single exhibition as they are a series of events. So, there will be a main Project folder, within which might exist something like the following:


As I see it, if I were to follow this approach literally within the resource tree, difficulties could arise due to there having to be two different templates - one for single events, and one for the containers of multiple events. To get around this I thought the most ideal solution would be:

1. Create a TV (most likely with MIGX) for the main projects resource where the client can add/edit projects, that would include the name, a summary, date(s) and so on
2. Create a second TV for new projects/events; a drop-down list of project names that would be populated by the first TV

This way, only a single template would be needed for each new entry, but those with the same drop-down option would be grouped by project name. However I'm a Modx novice and I wonder if I'm overcomplicating things with this approach - does anyone know of a simpler method? If not, which particular tutorials/rtfms should I be reading?

Hopefully this all makes sense - but I can try and elaborate if required.

Thanks.

why not a Resource for each project and a MIGX (or MIGXdb) - TV for the project-events (one or many)?

I think, I didn't understand what your second TV would do. [ed. note: Bruno17 last edited this post 12 years, 6 months ago.]

Quote from: Bruno17 at Mar 08, 2014, 01:07 AM

why not a Resource for each project and a MIGX (or MIGXdb) - TV for the project-events (one or many)?

Each event's content structure will vary, and so MIGX will certainly be used for each event.
But if there are many events within one project, wouldn't this require another MIGX TV to contain the unknown number of events?

In short, I see your suggestion as using MIGX within MIGX. Is this possible?

Edit: The second TV would be a way to allocate the event to one of the projects without having to manually adjust resource structure. [ed. note: chr.s last edited this post 12 years, 6 months ago.]

There are so many ways to do what you want that it's hard to know where to start. I think what I would do depends on how many projects and events will ultimately be in the database.

If it's a lot, the events should be in a separate table or handled by MIGXdb.

If not, I'd organize the resource tree just as you've shown with events as resources that are children of the project resources.

Either way, it's relatively easy for a project to detect how many children it has and display them accordingly using Tpl chunks. In fact, I think you could just have "Event list" as a heading and list each event under it using a Tpl chunk to format them. That way, you don't actually need to know how many events there are in the project.

Thanks Bob. I agree - the possibilities are vast, and I certainly wouldn't have an issue with maintaining either of the approaches. My main concern really is that it's as simple as possible for the enduser. I've made the mistake before of assuming that the client will be nearly as comfortable as I am with computers, which generally isn't the case; methods I thought were simple turned out to be daunting and unfamiliar to them.

I suppose in that respect, the question is: how do I let my clients most easily group events into the relevant projects?

As it stands, there's not a huge amount of events and projects. But I've no reason to suppose it won't grow. The idea of having them create a folder (or rather, creating a resource and setting it to container) and then adding resources to it seems the most OS-like way of doing thing. But this isn't an OS and the practicalities are very different - i.e. measurably less intuitive.

I think it may be a case of trial and error for now. But if anyone has a tried & tested technique they can recommend, I'd love to hear.

Edit: Perhaps this diagram will explain further; here's how the data could be organised:



Note that also each event and project would have its own associated image and text. Hopefully the pitfalls of a nested approach should become a little clearer. [ed. note: chr.s last edited this post 12 years, 6 months ago.]

Thanks Bruno - going through those tutorials now.

The beauty of MIGX is also its downfall - in my opinion - the amount of configuration required can be a little off-putting at times. That said, it certainly looks as though it's worth getting to know. An idiot's guide would be such a help.

I think your answer may be the one I'm looking for.

The beauty of MIGX is also its downfall - in my opinion - the amount of configuration required can be a little off-putting at times. That said, it certainly looks as though it's worth getting to know. An idiot's guide would be such a help.

I know, its not easy to understand, how everything plays together at first.
Once you know, how to configure this beast, I think it should be intuitiv enough, so far, and mostly self-explaining.
There are too many posibilities, to have a documentation for all of them and I prefer to spend my time with developing new features (mostly when I need them for customers) as with documentation, but I'm trying to help on the forums where I can and if one needs some special stuff, he can allways ask for paid work, of course.

Configuring a basic MIGXdb - TV or a MIGXdb - CMP without any special stuff for a custom-table including creating a simple xpdo-schema for a new custom-table, or the same for Resources of a parent, takes me less then, lets say, 30 minutes.

Well it's a good job I enjoy a challenge - and thanks again for your help and input. I think, once I can get it working, this will definitely be the way to go.
Annoyingly I ran into an error when setting up the migxchildresources configuration. I've also started another thread - if you have the time, your help would be greatly appreciated.