Monday, April 04, 2011 at 1:08 AM.

---

radio2Suite.utilities.initRiver2User

on initRiver2User (adrRadio2User) {
	<<Changes
		<<3/23/11; 10:21:40 AM by DW
			<<Instead of using the urlReadingList pref, set the user up so he is subbed to the reading list in his feeds table. I wrote about this in the change notes outline, excerpted below:
				<<I've been suggesting that when you set up a user, you set the urlReadingList element in the prefs table to point to the reading list and do all your work from there. This works great for fictitious users like east-village.org or wikiriver.org, but for real people, it's not the way to go. They can subscribe to a reading list just like they can subscribe to a feed, and that's the way to go. If you go the urlReadingList route, then all their subs have to go through that reading list. And their Feeds page won't work properly.
		<<3/22/11; 10:30:16 AM by DW
			<<Make sure there's a River2 user with the same name as the Radio2 user. If not, create one and init it.
	local (adrriverdata = river2suite.init ());
	local (adrriveruser = @adrriverdata^.users.[nameof (adrRadio2User^)]);
	if not defined (adrriveruser^) {
		local (adrradiodata = radio2suite.init ());
		river2suite.initUser (adrriveruser);
		adrriveruser^.feeds = radio2Suite.data.newUserFeeds;
		river2suite.initUser (adrriveruser)};
	return (adrriveruser)};
bundle { //test code
	initRiver2User (@config.radio2.users.adam)}

---

This listing is for code that runs in the OPML Editor environment. I created these listings because I wanted the search engines to index it, so that when I want to look up something in my codebase I don't have to use the much slower search functionality in my object database. Dave Winer.