In this case we only used *one* MODx resource for displaying each and every wine on the site, for all the reasons Jason mentioned above and more. Essentially you use a resource as a controller to display data from your custom tables.
is already getting close to the 1,000 mark.dont by worry, thats no problem, i am running a site with more than 5000 documents*56TVs, a lot of phx/snippets/templates/chunks(all in filesystem) and all is fine. The key is the caching. The parsing time is 2.0s 1350 Database queries from fresh and 0.08s from cache without any DB-query. The Backend runs stable and no other issus with it.(This is a point that sacred me.. i try to copy this site to revo and it runs slower)
I actually think @cipa’s recommended middle ground is a great idea - using TVs and resources does allow for rapid prototyping, but it’s in no way a replacement for custom tables when you’re talking about 1000’s of pages.Sorry, but this cant be right. What is the reason for using a CMS? To Handle content! No matter what kind of content it is. The content can turn into a homepage by a hap. But i want to handle my cars, magazines or whatever. How to handle the different kinds of content is a question for the "under the hood" people not for the user. Take a look to ezpublish for example.
$wine_id = $_GET['wine'];
$wine = $modx->getObject('wine', $wine_id);
Sorry, but this cant be right. What is the reason for using a CMS? To Handle content! No matter what kind of content it is. The content can turn into a homepage by a hap. But i want to handle my cars, magazines or whatever. How to handle the different kinds of content is a question for the "under the hood" people not for the user. Take a look to ezpublish for example.
I’ll say it one more time: I recommend you DO NOT use Resources to represent data that needs multi-faceted views. Your should never have thousands of Resources, as these are supposed to represent distinct, dynamic views in your site. The perception that using custom data tables to populate your views does not allow the use of Wayfinder or Ditto is IMO irrelevant, as you can (at least in Revo) very quickly create views from custom data tables. TV’s and Resources are for constructing layouts; IOW for presentation. Not for data.
All I’m saying is that it depends on your projectAbsolutely! I won’t criticise your position, just wondering about the statements about the use of modx. If this so, i totally misunderstood the great of modx.
Quote from: hk_modx at Jul 08, 2010, 04:39 PM
In this case we only used *one* MODx resource for displaying each and every wine on the site, for all the reasons Jason mentioned above and more. Essentially you use a resource as a controller to display data from your custom tables.
Dear HK,
In your scenario above, do you create friendly urls for each wine item, or do you use the id syntax?
One of the attractive things about the resource interface is the inclusion of things like friendly urls, etc. I’m not sure how we could include friendly urls if we skipped the resource interface.
It would be *very* useful if someone who has already programmed this kind of thing in Evo or Revo could post a zip file of code files, or notes, or something like that.
But I still think MODx has to be repositioned. This limitation wasn’t clear to me at all when I adopted MODx. I blithely went with the 5,000 resource limitation mentioned in the documentation, thinking that all was well.
Peter
This is great, really, but just a part of the truth. Who search the wines? who build a navigation through the wines? who make the friendly-urls for that entries?$wine_id = $_GET['wine']; $wine = $modx->getObject('wine', $wine_id);
The power of modx is flexible attributes (tv’s). Let’s say I have 4 types of data. I could either spend hours creating 4 CRUD modules- or I could spend hours working on modx letting it handle 1000’s of resources. I would rather make modx parsing and caching work better, because I can re-use that. Otherwise I’d just have to create a new module for each new data type.
And let’s not forget about the client. They NEVER know what they want. One of the best things about modx TV’s is no database migrations. If the customer wants a new ’image’ field, I can give it to them.
Quote from: hk_modx
Quote from: stefan at Jul 08, 2010, 05:29 PMAlso, see my post above for an idea of how to do friendly URLs with this kind of setup.
This is great, really, but just a part of the truth. Who search the wines? who build a navigation through the wines? who make the friendly-urls for that entries?$wine_id = $_GET['wine']; $wine = $modx->getObject('wine', $wine_id);
RewriteRule ^(events)/event/(.*) index.php?q=$1&event=$2 [L]
hallo hk,
Quote from: hk_modx at Jul 09, 2010, 03:09 AMQuote from: hk_modx
Quote from: stefan at Jul 08, 2010, 05:29 PMAlso, see my post above for an idea of how to do friendly URLs with this kind of setup.
This is great, really, but just a part of the truth. Who search the wines? who build a navigation through the wines? who make the friendly-urls for that entries?$wine_id = $_GET['wine']; $wine = $modx->getObject('wine', $wine_id);
RewriteRule ^(events)/event/(.*) index.php?q=$1&event=$2 [L]
Of course, your right, i also use such technique in a lot of projects and of course sometimes its better to make dedicated tables, its always up to the project needs.
But again, if you already have a integrated system that provide you a full functional EAV handling, so why dont use it for storing arbitrary content. Seriously, wheres the difference between your own table and the CMS-table? If you have thousands of events, of course, the manager-tree is not really a good solution to display them, but the storing itself must be out of the question.
ciao, Stefan
