Hello KDE/ownCloud fellows!
After one month of GSoCoding (and quantum information research), I am finally back to blogging. Let me be honest from the beginning: there will be no screenshots in this post :( This is because the first part of my project was entirely devoted to the most hidden layer of the aggregator app: the model part, the M of MVC (Model-View-Controller) — the pattern used in the design of ownCloud applications. In this post I would like to explain the details of my implementation and share some of the things I learned during the first weeks of my GSoC.
The most important entities in a feed reader application are collections and items. As you can imagine, a collection is a set of items. The collections are organized in a tree, whose nodes are the folders and whose leaves are the feeds. In my implementation, folders and feeds are objects of the classes
OC_News_Feed, respectively. These classes extend the class
OC_News_Collection. “Class”, “object”, “extend”? Yes, I am trying to design this app using object-oriented programming principles. I know, PHP is not the most comfortable language when you want to do OOP, but I still believe that this approach will make the code better organized. There are many aspects of PHP5 I could bitch about here (lack of a real overloading, for example), but I will rather refer you to this amazing post by Eevee. Anyway, ownCloud is written in PHP for very good reasons, so lamenting doesn’t really matter. I still believe it is possible to write nice OO code in PHP. <ad>A book that I found very helpful with regards to this is PHP Objects, Patterns and Practice by Matt Zandstra.</ad>.
The actual parsing of the feeds is handled by the SimplePie library (many thanks to its developer!). The interface between the SimplePie layer and the modeling classes is provided by some static methods of the class
OC_News_Utils. The aim is to make the SimplePie layer very independent from the rest, so that in future it will be easy to eventually replace it with some other RSS/Atom parsing library.
Another layer that needed to be decoupled from the layer of the domain objects is the persistency layer (in our case, the same as the database layer). An elegant solution for this is provided by the Data Mapper pattern. In a few words, a mapper acts as an intermediary between the memory and the database. It provides CRUD methods that output, or take as parameters, objects lying in the memory and map them to rows of the database tables. In my implementation, for each class
X describing a domain object, there is a class
XMapper for the corresponding mapper. As an example, the class
OC_News_FeedMapper contains the method
save which takes an instance of the class
OC_News_Feed and write the corresponding data in a row of the feed table in the database.
This was a brief summary of the design choices I have taken so far in my GSoC project. If you want to know more, you are invited to grab the code from the owncloud/apps repository – branch
newsapp. The classes I described above are all in the folder
news/lib. Since the official release of ownCloud 4, I am using the branch
stable4 of the main ownCloud repository as development environment (note that this changed since my last post, where I was suggesting to use the
The model layer is not perfect yet: some methods are missing, others need to be clean, not everything is very efficient, etc. Moreover, I haven’t tested it thoroughly. The main ideas are there, though. I’ve already started to code the interface part and I will make further improvements to the M part along the way.
Feel free to comment and stay tuned for a post on the V part!
Announcement: In about a month, I will start to implement the API. If you are the maintainer of a feed reader, please contact me if you are interested in syncing your client with the ownCloud aggregator. I would like to receive suggestions from you on the API before I start to code it.