How many template variables are sensible?

Hi,

Bit of a head scratcher here. I've been tasked to redevelop a directory site. It's currently run from a single Access table and the back end spits out static HTML pages. Each listing is an html page in its own folder so I'm thinking a resource for each listing. No worries there. The issue comes with the amount of variables. There are currently 174 columns in the db and that sounds like a horrendous number of TVs to me! Is it a bad idea to use that many TVs on a resource, or should I be looking at a CMP / snippet solution to display the data?

Any advice would be appreciated!

Cheers,

Chris

I don't really have an answer on a "right" number of TVs or if that has an adverse affect on performance or maintainability, but have you taken a look at MIGX, or, depending on your needs, MIGXdb?

MIGX makes it possible to group similar TVs into one repeatable modal interface. MIGXdb (which is brand-new) actually lets you interact with custom tables much like a CMP, but through the more familiar and MODx-ish TV interface.

MIGX docs:
http://rtfm.modx.com/display/ADDON/MIGX

MIGXdb docs:
http://rtfm.modx.com/display/ADDON/MIGXdb

Hey aladage,

I've used MIGX a few times and I love it. I've taken a look at the MIGXdb docs but they're pretty scant. Have you used it yourself?

Cheers,

Chris

No, I haven't -- I was also waiting for the docs to get fleshed out a little bit There is now a tutorial up there, which might help:

http://rtfm.modx.com/display/ADDON/MIGXdb.Create+a+basic+gallery-management+from+scratch+with+MIGXdb

There are currently 174 columns in the db and that sounds like a horrendous number of TVs to me! Is it a bad idea to use that many TVs on a resource

this idea realy isn't that good.


you can also create CMPs with MIGXdb the same way as its done in this tut.

Just create a new menue with parameters: &configs=yourmigxconfig

ready is your CMP

If you need more tabs in your CMP do &configs=yourconfigA||yourconfigB

I'm still working on it. If you like to experiment with it use allways the latest files from github! [ed. note: Bruno17 last edited this post 12 years ago.]

My first reaction to the question is that making directory entries map to resources is not a great idea, mainly for performance/scalability but also the content editor UX may not be optimum. That many TVs also introduces additional performance questions, especially if MediaSource paths have to be processed, category permissions have to be addressed, etc. All of this is hypothetical though, since I'm not sure what requirements you have.

Without knowing much more, my gut feeling would be to go the CMP / snippets approach. Alternately, you could explore the idea of a Custom Resource Class, which would allow you to combine what would normally be your CMP into the Resource Edit screen. In either case, the Resource would be the endpoint for all requests to that directory (a plugin or rewrite rule would handle mapping requests to it).

Before deciding on the best approach, also consider where and how the data in the directory will be used, how you would develop it and how it would affect performance. E.g.

• Do you need to aggregate directory entry data
• Search?
• Do you need to incorporate permissions?

There's a lot to consider, but it will be time well spent.

Hi Mike,

I think I'm leaning towards the cmp / snippets approach especially as there are so many fields in the mix. The reason I had considered a resource for each was so that they could be cached - how would the modx caching engine handle all the requests going through a single resource? I'd imagine it would need a fresh db lookup for each request. Speed is a big consideration here as we're moving from tiny static html files to a db-driven approach.

Cheers!

Chris

Hi Chris,

In your snippet code, you can take advantage of MODX caching. All of the Resource (partial page) caching and Element caching you're used to works behind the scenes, but it's using the same API that's available to you in your snippets. You can do database result set caching if you think your database connection will be a bottleneck. You can cache processed text for each combination of request parameters, or any identifier that is useful. (Or you may be able to cache the snippet itself depending on the parameters you are setting.)

Here's a good starting point:
http://rtfm.modx.com/display/revolution20/Caching
[ed. note: netProphET last edited this post 12 years ago.]

You definitely don't want to have 174 TVs.

The ideal thing would be to move the table into the MODX DB, create xPDO classes and map files for them, and use xPDO to communicate with the table. If you export the table from Access and import to MODX, you could go this route, since it's a single table: http://bobsguides.com/custom-db-tables.html.

Then, you could use a CMP to manage the data for you (a la Doodles) and a single resource with no TVs to display the data in the front end.


------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html