Yes, cron could do it, but reindexing the entire list of 100's of pages might not be efficient. Esp if it gets to be 1000's of pages. Timeouts and all... I think it would be better to just maintain the info there, in one place only.
The info extension plugin has a "mine" extension which would allow you to create an index like this from a batch of pages... some.page: 1234567890 otherpage: 1213141414 thirdpage: 1234323453 And BoltWire already has built in capabilities to update and retrieve these values easily. And generate fully templated reports. My guess is he wants a list of the next 10 upcoming events or something. And possibly check from various points in time. Like a calender of sorts. Each page link goes to the info for that event. If you wanted to do a full index of a group of index, there is an altindex= parameter in the normal indexing function which can be harnessed, just like site.index, but saves to a different index name. For instance, on my site I have the entire KJV Bible indexed in a custom index (static, never changes), and I exclude those pages from regular indexing. This dramatically speeds up searches on the rest of the site, and on the Bible also. I just have to specify which index to search. Unfortunately these powers may not be documented yet... As for speed comparison, I have a hard time thinking the time it takes to open one page with a list of simple field: value parameters and convert it to an array via preg_replace for templated output could be slower than a full database system with various levels of authentication and structuring and so on. A database is smarter when you have anything half way complicated of course, but an index like this is about as focused and straightforward a process as it is possible to get. I'm sure it would be equally fast or faster. Regardless, I would have to have a very real need to add the complexity of a database to my site. On my main site I have over 1500 registered members without about 15-20 profile fields each. To do sophisticated searches and retrieve information from that is a good use of a database. As usual it's the case of the right tool for the right job. Cheers, Dan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/boltwire?hl=en -~----------~----~----~----~------~----~------~--~---
