{"id":5,"date":"2015-04-13T17:01:00","date_gmt":"2015-04-13T15:01:00","guid":{"rendered":"https:\/\/daniel.liljeberg.io\/?p=5"},"modified":"2021-04-01T22:02:08","modified_gmt":"2021-04-01T20:02:08","slug":"data-objects-for-osclass-plugins-using-dlicore","status":"publish","type":"post","link":"https:\/\/daniel.liljeberg.io\/sv\/2015\/04\/13\/data-objects-for-osclass-plugins-using-dlicore\/","title":{"rendered":"Data Objects for Osclass plugins using dliCore"},"content":{"rendered":"\n

As mentioned in our previous post<\/a> regarding database tables for Osclass plugins written using dliCore the library offers another way to access the data stored in your tables. It was a thought that originated in an old library I did many years ago that I simplified for this case. The old approach consisted of something I called data gateways. These gateways would fill objects (that knew nothing about the back end storing the data) with data. The objects could be loaded and saved from each back end through the respective gate way. This made it quick and easy to change your code from working with the database to testing using mock-up data in xml files.<\/p>\n\n\n\n

For dliCore I took parts of this an made a system that would abstract the database layer for the developer and allow them to work with objects instead. I made it so that it would not require a huge overhead and it would also keep track of the fact that objects and databases were in sync. By that I mean that if you add a column to your table and you don\u2019t allow it to have a default value then it must be present in the object or an exception is thrown.<\/p>\n\n\n\n

Here I give a very simple presentation about how to connect an object to a table. Let\u2019s use a simple messages table in a plugin called userMessages<\/strong> in our example.<\/p>\n\n\n\n

Create table<\/h3>\n\n\n\n

First we create our table class.<\/p>\n\n\n\n

<?php\nnamespace userMessages\\Table;\n\nuse dliLib\\Db\\AbstractTable;\n\nclass MessageTable extends AbstractTable\n{\n    protected $_tableName = 't_message';\n\n    protected function _init() {\n        $this->_struct =\"CREATE TABLE IF NOT EXISTS \/*TABLE_NAME*\/ (\n        pk_i_id INT UNSIGNED AUTO INCREMENT,\n        fk_i_user_id INT UNSIGNED,\n        fk_i_sender_id INT UNSIGNED,\n        s_title VARCHAR(64) NOT NULL,\n        s_text  VARCHAR(256) DEFAULT NULL,\n        dt_date DATETIME NOT NULL,\n        PRIMARY KEY (pk_i_id),\n        FOREIGN KEY (fk_i_user_id) REFERENCES \/*TABLE_PREFIX*\/t_user (pk_i_id) ON DELETE CASCADE,\n        FOREIGN KEY (fk_i_sender_id) REFERENCES \/*TABLE_PREFIX*\/t_user (pk_i_id) ON DELETE SET NULL\n      ) ENGINE=InnoDB DEFAULT CHARACTER SET 'UTF8' COLLATE 'UTF8_GENERAL_CI';\";\n    }\n}<\/pre>\n\n\n\n
Our messages contains a id, a foreign key to the receiving user, a foreign key to the sending user, a title, the contents and a date time of when the message was sent. Indexes to speed up access by date etc could of course be added.<\/p>\n\n\n\n
Register table<\/h3>\n\n\n\n
Now we register the table with our plugin to it will be installed when the plugin is installed.<\/p>\n\n\n\n
class userMessagesPlugin extends Plugin\n{\n    protected function _init() {       \n        \/* Register Tables *\/\n        $this->_registerTable('userMessages\\Table\\MessageTable', 'message');\n    }<\/pre>\n\n\n\n
Creating our data object<\/h3>\n\n\n\n
Now we create an object that extends DbModel. <\/strong>We tell it which table it\u2019s connected to and we give it the member variables needed to carry the data. Note that we could add more variables here than what is available in the table and add additional logic as well.<\/p>\n\n\n\n
<?php\nnamespace userMessages\\Model;\n\nuse dliLib\\Model\\DbModel;\n\nclass Message extends DbModel\n{\n    protected static $_dbTableClass = 'userMessages\\Table\\UserMessagesTable';\n\n    protected $_id        = null;\n    protected $_userId    = null;\n    protected $_senderId  = null;\n    protected $_title     = null;\n    protected $_message   = null;\n    protected $_date      = null;\n\n    public function __construct($title, $message, receiver) {\n      $this->_userId  = $receiver;\n      $this->_title   = $title;\n      $this->_message = $message;\n      $this->_sender  = osc_logged_user_id();\n      $this->_date    = date('Y-m-d H:m:s');\n    }\n    public function getId()\n    {\n        return $this->_id;\n    }\n\n    public function setId($_id)\n    {\n        $this->_id = $_id;\n        return $this;\n    }\n\n    public function getUserId()\n    {\n        return $this->_userId;\n    }\n\n    public function setUserId($userId)\n    {\n        $this->_userId = $userId;\n        return $this;\n    }\n    \n    public function getSenderId()\n    {\n        return $this->_senderId;\n    }\n\n    public function setSenderId($senderId)\n    {\n        $this->_senderId = $senderId;\n        return $this;\n    }\n    \n    public function getTitle()\n    {\n        return $this->_title;\n    }\n\n    public function setTitle($title)\n    {\n        $this->_title = $title;\n        return $this;\n    }\n\n...<\/pre>\n\n\n\n
If a set<\/strong> function is present, that will be used when creating the object when reading from the database. So any extra logic needed on data read from the database can be put there. For instance you might store a data in some specific format in the database but want it to be stored differently within the object. If this need does not exist and there is no wish for any public get<\/strong> or set<\/strong> functions they can be left out.<\/p>\n\n\n\n
Functionality to save a single or multiple items and fetch items based on their primary key exists by default. Even multi-column primary keys are supported. To add extended functionality like we did in our old DAO object we can do things like this to our object.<\/p>\n\n\n\n
static public function fetchAllForUser($userId) {\n    return static::_fetchAll(static::getDbTable()->dao->select()->from(static::getDbTable()->getTableName())->where('fk_i_user_id', $userId));\n}<\/pre>\n\n\n\n
Working with your objects<\/h3>\n\n\n\n
By these simple steps you can now do things like<\/p>\n\n\n\n
<?php\n\nuse userMessages\\Model\\UserMessage;\n\n\/\/ Create message with user 10 as receipient\n$message = new UserMessage('Hello!', 'I would just like to say hello.', 10);\n\n\/\/ Store the message in the database\n$message->save();\n\n\/\/-----------------------------------------------------\n\n\/\/ Create and store a batch of messages at once\n\n$userIds  = [1, 2, 3, 4, 5, 6, 7, 8];\n$messages = [];\n\nforeach($userIds as $userId) {\n  $messages[] = new UserMessage('Hello!', 'I would just like to say hello.', userId);\n}\n\nUserMessage::saveBatch(messages);\n\n\/\/-----------------------------------------------------\n\n\/\/ Fetch all messages for a given user and echo them\n$myMessages = UserMessage::fetchAllForUser(osc_logged_user_id());\n\nforeach($myMessages as $myMessage) {\n  echo $myMessage->getTitle() . '<br\/>';\n  echo $myMessage->getMessage() . '<br\/>';\n  \n  \/\/ Deletes the entry in the database and sets object to null\n  \/\/ _beforeDelete is called on the object before object is deleted from db\n  $myMessage->delete();\n}<\/pre>\n\n\n\n
Closing thoughts<\/h2>\n\n\n\n
If one opts-in to use this style you get an easy encapsulation of objects without much work. For the standard tables like User<\/em> these objects will also be made available by the library. That way, user objects can be passed around instead of user id\u00b4s or associative arrays.<\/p>\n\n\n\n
Note that just as with most parts of dliCore, the use of these objects are purely optional. You can stick to just creating the tables in this new way, or doing it the old manual way and sticking with DAO your old objects. For older plugins being moved to use dliCore this can help reduce the needed modifications.<\/p>\n\t\t\t\n\n\n
\n
Comments<\/h3>\n
 \n
\n\t<\/a>\n\t
\n\t