Thanks for the suggestion regarding using a decorator for the DataObject. I have actually used a decorator for my MemberRole class. I extended it to accommodate extra fields, and has_ relationships, etc. But for my Article (my Publications) and LibraryItem ,etc classes I just extended the DataObject class. I based my MemberRole class on Aram's SSbits tutorial 'Registering Users and allowing them to edit their details' but I didn't really understand all of the underlying code behind it.
Basically a decorator (I think Rails calls it a Mixin) hooks into another class rather than extend it. This is especially useful if you can't really replace an existing one - for example Member as the CMS uses it in /admin/security. So you want to inject your own attributes into it, which a decorator does for you.
So if you also want to rate users, providing a (probably abstract?) DataObject won't work too well for you. But I don't know enough about your exact scope to give you a finale opinion.
I think that is part of the main problem I've had using SilverStripe - I've found various tutorials which help me but I don't always get all of the underlying architecture choices.
IMHO it would be important to further specify the kind of metadata as this will have a big impact on both scope and recommender.
Specifying the initial metadata is key. But there are almost endless choices - most dependent on specific implementation needs. I'm wondering how complex I make the initial module. Would it be better to provide for the most popular metadata choices, to be determined, in a basic module that can then be extended/adapted by the user using decorators? Can you use a decorator on a decorator? For example, if the
SocialMember and SocialObject extend DataObjectDecorator with basic data
and methods will a user be able to easily extend them?
I must admit I've never tried to extend a decorator two or more times, but this should IMHO be possible.
However don't make it too complex. Additionally adding layer upon layer sounds nice in theory, but it gets harder to handle and slower with each layer (OOPs spaghetti code is lasagne code - layer upon layer ;-) ).
I'd settle for a set of sensible parameters (probably tags, ratings, locations) and keep that extensible. You don't need to cover everything.
Also some of the metadata will also be DOs - tags, reviews, etc which will need to have a many_many relationship to both the SocialMember and the SocialObject. I'm not sure if each of these will need to be there own separate module? I'm using the tagfield module now. Is it being updated for SS3, do you know?
I think Ingo has written the module and is maintaining it - I've never really used it and can't say too much about it.
I also noticed that the tagfield module says to create a tag DO that extends the DataObject rather than using a decorator. Is there a tutorial or something somewhere that I can read that can explain when its best to extend a class and when its best to use a decorator?
Tried to explain above - maybe Ingo can add some feedback on the specifics of the tagfield module.