building the foundations of a social network framework [to be continued]

Since I pondered on implementing a social network for weeks, this weekend I might have some time to get something up and running. It’s plain to me that I am new to Rails, and I probably will miss several important points. (For the same reason, I don’t dare to approach to comprehend how the LovdByLess framework works.) But nevertheless, I want to get my hands dirty and a least bit up and running. Following Rails’ approach to get things visible, I want the thing not only up and running but visible as well.

The goal is set — to build a level I social network. What does that require? Login and contact list. Which in turn, at least need a user profile page — for the users themselves to have something of the least value for themselves, which might constitute a minimal incentive to join. Additionally, that thin social network would need a user search — how else should one user even find another user to friend them? And also a contact list to manage all the friended people.

In a second thought, I remove the search from the list, because my goal is to do nothing but implement the basic functionality of that system. Therefore, why regarding incentives for users at all — during the current stadium, i.e. while attempting to get most fundamental functionality up and running? User search would allow to enter partial user names, get out matching user names i a list, plus the option to add any of these user names to self’s contact list.

But if we ease the implementation by skipping to provide a user profile page, then why searching at all? Obviously, now, our goal’s not longer to help a real user but instead to get the basics up and running. So: Why list the user names only if they were searched? Why not just list them all and always? — Therefore I remove search althogether and keep only users list and contact list.
 

Therefore, our goal — for now — is to render a users list. Each entry shall consist of a render of the user name and an add to my contact list link. Whereby the latter implies that there is a ‘me’ (or ’self’) user to whose contact list the add whould get performed on.

The users list would consist of user objects. Every user object would render itself by displaying its name but also an add to ‘my’ contact list link. The contact list would not be rendered here but get accessed by the add to ‘my’ contact list link. To ease playing around with this system while there is no real user management, the user list could feature a user X shall be ‘me’ link and a show this user’s contact list link too (rendered by the respective user object). Like this:

From a database point of view, every user would belong to the users list. There would be only one users list. One contact list would belong to every single user. In turn, there would be x users per contact list. To sum it up, we would have one users list, x users per users list, one contact list per users, i.e. x contact lists, and y users per contact list:

To get this into a Rails project:

1. Set up a Rails project, say level_i_social_network:
   $ rails level_i_social_network
   $ cd level_i_social_network
2. If you use MySQL, have a look into config/database.yml to make sure you indeed can create the database needed. I.e. make sure Rails learns about necessary passwords. — At least for those Rails on Debian Etch installations I’ve seen so far, the database defaults to SQLite3 instead of to MySQL, therefore there is no need for database setting changes before even creating the database.
   To do so, create the database by
   $ rake db:create:all
3. Then, create the tables needed — first prepare them, then actually create them. — Since we’re about to deal with more but a single table, this is going to be a bit more tricky than what you might be used to from those 7 minutes all what Rails can do for you videos. Hence, we’re going to go a bit deeper into these matters.

To get deeper into that matters, currently, I am after to figure out in which order to scaffold the necessary tables and how to go further from there. To do the scaffold at all is relatively easy. You do:

$ ./script/generate scaffold \
        Userlist user:references
$ rake db:migrate
$ ./script/generate scaffold User name:string \
        contact_list:references
$ rake db:migrate
$ ./script/generate scaffold Contact_List \
        contact:references
$ rake db:migrate

(As usual, the ‘\’ indicates that the next line is to be appended, i.e. shall replace the ‘\’ character.)

But, as said, I am not sure whether that is ‘the right’ — or at least any right order at all. The second part I am after — and which probably would decide whether or not the beforementioned order is right or wrong — is to go through the generated scaffolds to configure the Active Records. By that I mean: I want to make explicit what’s called ‘references’ in the command line (and hence in the generated ActiveRecord descendants too) and — if that’s possible and usual in this stage — to get the several items rendered, maybe even and interactable.

I could need some help here.

While I try to surpass this hurdle, you might try in parallel. For that reason, I blog this posting this early instead of fighting me through the barriers first. Maybe someone of you can figure it out before I do and post their solution here into the comments.