XoopsObject Extends Life

XoopsObject is one of the worst classes at XOOPS. Onokaz admitted it. But, it's difficult to introduce new classes now. I think that most module developments will become RAD base. Therefore, if the code of the class is cleaned up, problems are few.

We made XoopsSimpleObject and XoopsObjectGenericHandler. XoopsSimpleObject implements the common interface of XoopsObject that we abstracted. See the class dialog:


XoopsObject has turned deprecated. But, XoopsSimpleObject is useful for beginners that don't have the original class or famous libraries. XoopsSimpleObject has Type Safe features, simple access methods, only 5 DTYPE that is BOOL, INT, FLOAT, STRING, TEXT. Criteria class is separated from SQL, and XoopsObjectGenericHandler generates SQL by Criteria with Type Safty.

Criteria class has turned the information structure for dynamic SQL. Criteria::render() is deprecated in XC 2.1.

Plus, some tools support developers. I have never written the subclass of XoopsSimpleObject directly. I always use the tool to use XoopsSimpleObject. I believe machines than me.

We don't force it. But, if a developer doesn't understand the problem at accessing DB, he should use XoopsSimpleObject and tools.

BTW, XoopsObject has many weak points and some merits. Because Criteria:render() is deprecated in XC 2.1, you can use it to anything. XoopsObject is separated from DB by handlers. Therefore, XoopsObject, Handler and Criteria are abstract. You can use Web Service by using such classes.

$handler =& gethandler(...);
$criteria = ...;
$objs =& $handler->getObjects($criteria);

Developers don't need to know where you got the object from. It may be DB or Web Service. But, irrespective of DB or Web Service, developers don't need to change their code. I think that this thing will become important in the near future. It seems useful for the bridge technology.

But, the feeling may be from my experience that I'm an amateur. It may be no good for professionals.