humaniweb, you have quickly found a big problem with the "all content is content" mindset. I have found your question stimulating, as it has made me look again at how I will integrate MODx with my various projects.
Should every "content" be a "content" ?
For example if i add a template variable to my "products" which is the area where the product is grown or manufactured. I will add a popup filled with data retrieved from a database (of cities for example).
How do i manage my cities ?
In ShopX and MODx the easiest route is to just store the same text multiple times. But you are right to realise that it is better to store '61' and cross reference that elsewhere to the city name "Bombay", so that you only have to change the name to "Mumbai" in one location.
If we go down the "content is just content" path, then you might expect that content is equal, and thus you would add a "Cities" folder, and put a new content document for each city. Which itself could have a set of TVs for countries, which would reference other content. However, there is no easy built-in way to create a TV which lets you pick from MODx content, let alone pick from just specific information!
It is possible to use Data Bindings:
http://modxcms.com/what-are-at-bindings.htmlwhich could refer to other MODx content, as in this example:
http://modxcms.com/select-binding.htmland you could extend that to be every content that is a child of a "City" folder.
Thus, if all your cities were inside the Cities folder, which was document ID 3, you could use a TV with a Drop Down List Menu and the following Input Option Values:
@SELECT pagetitle, id FROM modx_site_content sc WHERE parent = 3
Clever, isn't it?
But... now when you edit a City you have to edit a document.
So you have a dozen or so document-specific fields for each City that you will never ever use, and could be described as inefficient. Sure, you could decide to actually have a page for each city, and if you placed in the content of that a routine that displayed all the products made in that city, having per-city pages would be quite neat.
But not _all_ such data lends itself to "also being a document".
If you are more comfortable having a dedicated Cities table, you can create one using normal means and bind to that.
Or you may have existing tables from another application that you want to bring over - these can be referenced easily with Data Bindings if you are familiar with SQL.
But with both, you would have to write a plugin for the manager that edited cities. Or wait for someone to write a
Database Table Editor like that discussed in the wishlist forum.
I love MODx, and ShopX sounds like a real labour of love. But the present release is only a proof-of-concept. And that concept is "you can build something that looks like a shopping site with MODx" rather than "you can list lots of products with high data integrity and sell things to people worldwide in a logical and time-effective manner".
So yes, humaniweb, you are right to query this before you delve in, to see if there are guidelines. MODx is flexible, which means you don't _have_ to do things the "content is content" way. Do things the way that is quickest for you.
Only when MODx has the ability to distinguish between content types, and lets you present a different content editor for 'cities' than for 'products' or 'pages' will it truly be flexible and simple.
MODx is an awesome content management system. One day (possibly soon) it can also be an awesome data management system. ShopX is pushing the boundaries of content management.
