Services:BlogService
From MacroDeckDevWiki
BlogService provides functions (layered on top of DataService) for blogging, such as creating, editing, and deleting posts. Because this depends on DataService, you must start it after DataService.
Contents |
Concepts
Every user and group has a blog that should be created by your Rails controllers when they are created. The owner field should be set to the group or user UUID and the creator UUID should be set to the system UUID (or, if created by a user/admin/etc., their UUID). A blog is a data group, and blog posts/entries are data items belonging to that grouping. Each post/entry, however, also has an associated data grouping for the set of comments associated to each post/entry.
Additionally, every post item, blog group, comment, and comment group can have a title, description, and tags/keywords. In some instances, it may be needed. Note, however, that this information applies mostly to searching and sorting. For example, a comment's description/tags are going to be meaningless under most circumstances, except for maybe if the creator of the entry goes back and tags the comments. In the future, DataService will have functions for handling this quite simply.
Comment Storage
Comments can in theory be written by anonymous users. Because of this, the best way to store a comment is as follows.
1. The comment body should be stored in the stringdata field of the comment data item.
2. Extra comment data (such as username, comment title, url, e-mail, etc.) should be stored in the same data item's objectdata field. This means that the stringdata and objectdata fields will have data.
3. The object that represents this extra data should be a hash that looks like this:
{ :name => "My Name To Display", :url => "http://www.macrodeck.com/", :email => "someone@microsoft.com" }
4. Of course, for logged in users, the software should rely on the creator UUID (if it's not the guest creator UUID) for getting that information. So, for logged in users, you can safely not store anything in objectdata.
Future
BlogService will probably handle remote blogs (via RSS/RDF/ATOM) in the future. DataService would handle the data loading and parsing, and BlogService would handle the representation. So, given you know the remote blog's UUID (which would be easy to lookup and find), you could retrieve it like any local blog. Except that it'd be read only.
Because of this, BlogService will need some code restructuring (around improved DataService) to correctly handle this kind of situation where it can't always have full control over the data. Expect to see these improvements in Services 0.2.
See Also
- DataService -- provides underlying blog storage
- UserService -- provides user, group, and permission support
This service has RDoc documentation here.
