is @SELECT bad form in Revo?

But nothing in the core of MODx cares or wants to have anything to do with sidebars or any part of how you layout and organize a site.

You will find we avoid as many analogs with Joomla! as possible. But seriously, the MODx approach to building sites without monolithic "modules" and/or "blocks" is an important one.

Anyway, the point of this thread though was simply alternatives to using @SELECT. IMO, using Snippets is preferable to @ bindings when you need to get direct access to dynamic data; we just need to add the ability to use these in the Template Variable input options.

Anyway, the point of this thread though was simply alternatives to using @SELECT. IMO, using Snippets is preferable to @ bindings when you need to get direct access to dynamic data; we just need to add the ability to use these in the Template Variable input options.

The reason why I detailed this example (and because the OP also decided that it wasn’t just @SELECT but specifically querying MODx tables) is because I assume that where possible, the modx design would prefer that modx objects such as chunks would be accessed via a more rigorous API (like $modx->getChunkNames([category]) for example) than via xPDO or querying modx tables directly. This allows for a better upgrade path.

xPDO provides the consistent API that protects your upgrade path and abstracts direct database access. So enabling the use of xPDO/MODx API calls in Snippets (or interpreting any MODx tags) in the input options is all we are discussing here.

I’ve tried to abstract this question to make it more globally useful; the specific binding I’m trying to do is get a list of all chunks of a particular category.

Err - the OP is discussing methods of accessing lists of chunks in a category. That is what is being discussed here as much as anything.

Yes the general for SQL access would be solved by xPDO access via TV inputs - but the more specific case of accessing modx objects such as chunks to develop dynamic TVs based on chunks or documents?

It would be good if API calls could be made from TV inputs also...

Quote from: paulkoan at Mar 09, 2010, 04:46 PM

Err - the OP is discussing methods of accessing lists of chunks in a category. That is what is being discussed here as much as anything.

Er, well, the topic is "Is @SELECT bad form in Revo?" and I am suggesting that yes it should be considered bad form. In addition, I was identifying what needs to be done so that we can remove our dependence on it in the near future, i.e. address the access it provided historically, such as this one example.

Yes the general for SQL access would be solved by xPDO access via TV inputs - but the more specific case of accessing modx objects such as chunks to develop dynamic TVs based on chunks or documents?

MODx is xPDO extended, so maybe you are just not understanding that the same methods are used to access any xPDO-based object. MODx provides some extra methods related to the CMS domain, but for all intensive purposes you are using the xPDO API when you do anything with the MODx Core in Revolution.

It would be good if API calls could be made from TV inputs also...

That’s what a Snippet provides, the ability to call API methods, so yes, that is what I am suggesting by allowing MODx tags to be processed inside these values.

But I appreciate that the API cannot abstract everything I would ever want to do, and so xpdo is certainly a lot better than direct SELECTs.

<?php
class modX extends xPDO {
...
} 

class modResource extends modAccessibleSimpleObject {
}

class modAccessibleSimpleObject extends modAccessibleObject {
}

class modAccessibleObject extends xPDOObject {
?>