ShopX and MODx - Need Guidance or Guidelines

Hi all,
First of all, thank you very much for Modx which seem to be a pretty cool tool.

But... but i think i need some help, or guidance or guidelines to start developing with it.
For example the first thing i was looking for was an ecommerce module.
I found ShopX.
Cool.
But i found that for example a product is the same thing that a content.
Is it the only way to do something with modx ? 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 ?
How is it possible to "extend" the manager of Modx and how this sould be done ?

I think a need some guidance to understand the way of working of ModX and beginning to seriously use it.
I hope somebody will be able to help me and maybe... why not... creating a sort of tutorial/guidelines for new users of ModX...

Thank you very much again,
Sorry for the bad english,
Julien.

You’re really close and your english is WAY better than any other languages I speak. In fact, it’s a lot better than many people in the town where I grew up...

To your question. The MODx view is about flexibility and simplicity. Content is just content. Need extra things to describe the content, add some Template Variables (TVs).

ShopX is undergoing a ton of great work that will be released soon... it’s one heck of a neat demo of the power and flexibility of MODx. More soon...

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.html
which could refer to other MODx content, as in this example:
http://modxcms.com/select-binding.html
and 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:


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.

If I recall correctly, I’ve mentioned several times that this is suitable for a small, simple shopping site. And that it was primarily conceived as a proof-of-concept that sort of got out of control. But it is very usable for what it is intended for. One doesn’t use a paring knife to chop firewood, nor does one need an axe to cut a piece of cheese.

Hi all,

First of all, sottwell, i’m sorry to have taken shopx as example. In fact, i don’t criticize or speak about shopx, i more ask a general question because i want to use modx and i’m facing some big questions that i prefer to resolve before going further.

Thank you very much PaulGregory for your post in which i found almost all the answer to the questions i was wondering.
Having "a dozen or so document-specific fields for each City that you will never ever use" is exactly the kind of situation i would like to avoid so I will dig deeper on this Database Table Editor plugin as it seems to be what i need.

I completely agree with you all that modx seem to be an awesome tool with some boundaries that (i hope) can be pushed further.

If some developer (as i’m not a great one myself) as already worked on this "Database Table Editor plugin", or if this is a future development in modx, can you tell me please ? In order not to do the job twice... and maybe helping in developing/testing/correct it... ?

Thank you very much all for your support,
Julien.

Ok...
Thanks to en8scl, i’ve downloaded turbodbadmin and begun to wrap it in an iframe in order to embed it into modx (via a plugin).
I’m not a very good developer and what i’m doing is not very clean but i hope this will give some ideas to the modx team.
I’m also modifying turbodbadmin in order not to list all the databases nor tables.
I will let you know when something can be tested and viewed.

Julien.

@humaniweb - Glad I could be useful. Interesting that you have taken a wishlist item (a desired thing) and forged ahead with adding something to MODx! You should keep an eye on the Table Editor thread, it looks like any solution for MODx 1.0 will be vastly different to whatever you manage to hack together now - which in a way means it is a good time to knock out a "not very clean" editor.

EDIT: Indeed, you should probably post on that thread so people know what you’re doing, although I have now mentioned it.

@sottwell...
Quote from: sottwell at Jul 13, 2006, 01:12 PM

If I recall correctly, I’ve mentioned several times that this is suitable for a small, simple shopping site. And that it was primarily conceived as a proof-of-concept that sort of got out of control. But it is very usable for what it is intended for.

Yes, I’m sure it’s great, and I hope no-one infers anything from my comments other than the converse of what you say there - that it is not suitable for a larger site. Around a quarter of the ecommerce sites I’ve ever been involved with would find your solution perfectly adequate.

But the question is how you move from that to a less-simple shopping site (of any size). I believe this requires a conceptual shift into data rather than content. My belief does seem to differ from "the MODx view", but the real flexibility of the system is that people can go both ways.