is MODx Revo a good fit for a Yelp-style site?

Hi all,

I've used MODx Revo in the past for a couple of projects and really like it as a CMS, I'm just wondering if it's a good fit for a project I've got coming up. The site is to be a bit like Yelp with a much narrower focus, but from a data/structure standpoint it will be quite similar.

However when thinking it through a bit more, I don't want to have each listing sitting as its own resource within the tree - that won't be scalable longer-term when trying to use the resource tree. So maybe I need to code up something similar to what Articles does, but specific for the website requirements. I'm completely open to suggestions though if there's a better way.

Anyone know how much work would be involved with what I'm thinking? I have no problems creating the DB tables, setting up relationships, etc, I'm more concerned with creating a good user-interface for the Manager backend that will be robust enough to deal with potentially thousands of entries.

1. Use resources with Collections - the child resources are in a grid in a new "Children" tab of the Collection parent resource.
http://rtfm.modx.com/extras/revo/collections

2. Use a custom table with MigxDB. See the tutorials for examples of what you can do with it.
http://rtfm.modx.com/extras/revo/migxdb/migxdb.tutorials

You might also look at using ClassExtender to extend modResource, which does something similar to Articles (though without the UI and without changing the class_key). It will give you *much* faster Searching and Sorting than using regular Resources with TVs would.

In addition, you might consider Quip, which would provide a UI for the reviews, store them in a custom table, and attach them to the appropriate "Resource" object.

Thanks for the replies, Susan and Bob (and Bob for your excellent book).

MIGXdb could be a good fit for this project... I'm just struggling over relationships with child tables in the DB and I was wondering if either of you or anyone else can comment.

What I'm trying to achieve is this:
- the user can save a facility type to the database, e.g. a tennis court or swimming pool
- different "types" of facilities have different data to be saved specific to that facility, e.g. tennis: number of courts / court surface, swimming pools: pool length / indoor/outdoor.

I thought to model the 2nd part with child tables in the database, or at least I'd do that if building the tables myself in MySQL. But with MIGXdb, do I try to nest MIGXdb's? If so, how can I get it to select a different MIGXdb based on the type of facility? Also, I can set everything up, but the people doing data-entry are likely to not be technically proficient so I don't want the UI to be overly complicated.

You could use MIGXdb for this, or you could use extended resources, as Bob says. Each type of facility would get its own extended resource, with its own relevant fields. The extended resource would probably be easier for your data entry people, as well as easier for searching and organizing.

Thanks Susan, I'll definitely look into extended resources then

Before going further, I think, a good start would be to plan the needed db-model.
Normally, I start with building a simple xpdo-schema with proper relations defined between the tables and let MODX create the tables (with help of the MIGX-CMP)

If you could show us a (maybe simpified) xpdo-schema of your tables and its relations, which you have in mind, I can tell more about, how you can model the CMP with help of MIGXdb

If fields do not need to be searchable, you might think about storing them as json into one field.
If you have many different facility-types and you can't plan, which fields you need, you might think about having something like TVs related to your items.

I think, I wouldn't create different tables for different facility-types, if possible.

And yes, there are ways to have different input-forms for different facility-types within one grid.
Also nesting MIGXdb-grids inside another MIGXdb-grid is possible, if that is needed.
Or having MIGX - fields, which store its items as a json-string into one field, for example for images, if they do not need to be searchable is possible.

Didn't mean to belittle the capablilities of MIGX, Bruno. That's one of the greatest strengths of MODX, there's always more than one way to do anything, and it would be hard to point to any one way as the "best" way. Actually, it would be very interesting to see this implemented in both methods.

No no, using (extended) resources has its advantages.
Think about friendly Urls out of the box.
Having ready-to-use commenting-tools.
Can besides the extented-table still use TVs, if needed.
And more for sure.

Actually, it would be very interesting to see this implemented in both methods.

Or a combination of both

Hmmm... yes, I see many possibilities in that idea. I will take it to another forum so as not to hijack tuz's thread.