Quote from: OpenGeek at Apr 14, 2006, 01:32 PM
That’s up to you, but I’ve had no trouble keeping any kind of data in the DB as a string of content, especially since PHP can automatically get it as the type it needs to work with in most cases. But beware of the range of numbers between 700 and 884 if using numeric data types.
Very true. It’s just that the site I’m working on has for example a database that currently has like 150 records, which each has like 60+ numerical fields and that database has to be able to handle over 1000 records so keeping every number as content just sounds scary because I feel the overhead will be too much and I think that good programming rules say that one should at least try to keep numbers in numerical fields in a database. So I guess I’ll have to mix up something myself to interact with MODx.
There is one thing though that I’d love to see in MODx...
The ability to create custom document types. For example having summarizing text might not fit for everyone so it would be cool to create a document type that wouldn’t contain it. Another example is that if you want like 2 or 3 text fields and then a few numerical fields. The reason why I think it’s cool is that by creating those then you can force your content editors to provide ceirtan data and so it is easier for you to deliver content in a consistent way. Another reason why I think it’s good is that it makes it easier to work with the data. For example if you had a bunch of documents about players and you wanted to analyze their points etc then it would be super to just have a column in the database with all their points. Of course it’s possible in the current system but I feel there is just too much overhead that follows it in the current system.
So instead of having the content field and summarizing field in the current content table you have then you could have "pointers" to tables that actually contain the main content in your document. So when a user would create a new document type then he would basically be creating a new table in the database. I think this can work because there are very finite options of what kind of input you can have (for example rich text, short text like for titles and stuff, numbers, boolean fields and maybe fields where you are picking something from a finite number of options).
One nice feature would be that maybe the main admin creates a folder, let’s call it player profiles, then creates a special document type for it. Then he assigns some content editors to that area and if they use the manager then one could have that new document type as the default document type for that folder and so when they are adding new documents then they get all the right fields up and what not.
But wouldn’t that kind of system be too hard on new users with little CMS experience? Well of course you’d have the default document type and new users wouldn’t have to bother at all with creating new document types.
But then again, I just might be whining and talking nonsense, lol. I know it aint good practice to throw out ideas and then not offer to help coding so I’m sorry about not offering to help :’( But then again the idea sounds like it would mean messing around with the core and if I were you I wouldn’t let a programming noob like me touch the core
MODX Staff
MODX Staff
-- to fully integrate custom database tables into the cms system and a great many of the numerous typo3 plugins do just this. You can define custom document types which are linked to matching custom forms in the typo3 backend (=manager) to add the appropriate information to the matching database tables. I need this feature very often, as many of my customers have some kind of structured content to manage: publications, events, products, persons, addresses etc. all with unique attributes (= database fields). 
