a general database 'framework'

[kermit]

This is a module idea. Perhaps it has merit enough to be considered for the core, considering how flexible it could become. I think it would be well received by the folks that use CMSMS now.

I have seen something similar for a couple other CMS packages, but exactly what or where, I can't recall right now.

I picture a module that allows you to create a database (well, multiple databases actually) of information, whether it be a business directory, links listing, FAQ, etc, might even work as the foundation of a simple ecommerce catalog (that could then in turn be interfaced with something like Paypal). I don't think it needs to be internally relational itself, as that would cause some UI headaches from the added complexity. A flat table-like structure would likely be good enough.

The idea is that each 'database' is set up and configured separately, so you could have multiple ones, each with different structure and data, on the same site. Output to the user, of course, would be via templates and CSS.

The module would allow creation of more than one of these 'databases', with specified number of fields in each record, and maybe the general format of fields (text, number, URL, image). I don't know if you'd want to go so far as to have strict field formatting rules like in ms access and other db apps though (again, added complexity to the UI, and logic).

It'd allow to browse and display lists of records based on criteria; field1="some term or expression" or a query of all the unique items in field1 (which would be like a 'category' list), and then drill down to see matching records and optionally to an individual record's detail on a single page. A 'search engine' internal to the module would be of benefit, allowing searches on a specified 'database' (or specified list of databases) from a search box.

I'll try to explain how it'd work from the site visitor's end using the simple concept of a links directory:

So, you have a menu item "Links" that takes you to a page generated by the module that was a list of "categories". Categories in this case would be a list of each unique entry in the field "category". Perhaps this category list also displayed the number of records in each one. From there, clicking on a category name would bring up a list of all records that matched that category. That list might be complete enough by itself (with site name and URL at minimum), but click on the site name and you get a details page with perhaps a small screenshot and a longer site description or review.

The same module concept could be used for a business directory, FAQ, real estate guide, documentation, articles, classifieds, downloads repository, jobs listings... the possibilities are pretty endless. And as I mentioned above, from there, it wouldn't be hard to interface with a third party API like Papal to make additional use out of this organization of data.

additional functionality that could be included at some point down the road could include: a "news-like" tag to insert "what's new" or "what's hot" into site content or templates; front-end user commenting, rating and submission; RSS feeds of new entries (by defined criteria, database, or site wide); and import/export routines.

I'm not talking about a database that you could import the Chicago yellow pages into. Just something that can accept, display and organize a reasonable amount of data.

attachment is this post in plain text.


[attachment deleted by admin]

[kermit]

unfortunately, i'm not a programmer. i deal mainly with hardware & applications, and a little server administration. design & hosting are just a couple of the things i do. haven't programmed anything more than ms batch files since the late 80's.. except for some simple hacks to existing scripts. now if someone could come up with a 65xx assembly to php converter, then i might be in business. 

as far as core vs module. i think something like this is a viable candidate for inclusion into the core, simply because it would expedite the addition of other potential core features, such as a faq, kb, links directory, ad banner management, rss aggregator (all could use one of the 'databases' to store it's data), etc.

it could even be used as the method of storing some of the standard cmsms data (articles, news, user list, etc).

[roman]

hi kermit, i'm creating SQL tag, not running yet, but later can by module http://svn.cmsmadesimple.org/svn/sql/

[calguy1000]

This module would not, in and of itself be that difficult to write, as I think the formbuilder module could also be used for this, it is though, as always an issue of time, or the lack of it.

However, I don't feel that this should be a part of the core, it is definately an addon, though an addon that would be very popular, not all sites would need it.  And of the sites that did need this module, they would want a variety of different behaviours from it.