#145 OO approach to Content, Version Control, Abstraction

[ajaksu]

Version Control -> modules and users with access to
modules have far too much power IMO: you can erase
content, you can garble content, you can hit the submit
button after erasing all the text, etc. I think a
killer 'core' function would be having data
replication, with hooks for retrieval (modules would
have to implement that). No need to replicate data
structure, a simple table for serialized content would
do. Auditing logs would be awesome. So backup/version
control/data safeguards' would be my 1st RFE.

Content -> OO is great for many things, and IMHO one
of them is content management. Many modules have
similar DB fields, many have similar content. If
modules could be built using core datatypes or
'column-types', building APIs for interoperability
becomes interesting. Say MyCalendar has 2 content
tables: xoopsdate_mcdate and xoopstext_mcevents,
instances of the xoopsdate and xoopstext tabletypes.
When someone codes YourNews, if it has a
xoopsdate_ynpublished column it can ask MyCalendar what
happened when the article was published. If my article
needs to add a date to MyCalendar or any other
calendar, it'll export a xoopsdate object that somehow
fits in that calendar if it uses this kind of
column-type. Methods for base column-types (dates,
numbers, text, sanitizing, whatever) could be core...
and extensible + inheritable :) This goes further to
Abstraction:

Abstraction. E.g., modules wouldn't talk raw to the DB.
Dozens of modules have dozens of SQL commands saying
"this field will be full-text search, this one will
auto-increment' that could be defined in core: my
module will use an instance of xoopsdbtextFT, two of
xoopsdbdate and one of xoopsdbcomment, wrapped in a
XoopsModule. SQL structure for xoopsdbtextFT,
xoopsdbdate and xoopsdbcomment would be generated by
core, making easier to have different generators for a
given module DB structure. SQL commands for module
operation need abstraction, it makes no sense to
require SQL version lock-in and hardcode things at
module level AFAIK (perhaps to avoid overhead and
performance issues?). Modules don't need to talk raw to
URLs, images, users (already works like that), display
(sorta works like that), input (being implemented?),
content (what this '2nd' is about), etc. IMO modules
don't need to be 'single-install' and being able to
clone/duplicate/extend modules would be easier if they
were OO regarding content (namespaces? private/public?).