wiki | forum | trac | otrs | joomla | tech blog | mailman | bewelcome Branches: test.bw | alpha.bw | www.bw Participate: download | get involved

Ticket #396 (assigned new feature)

Opened 10 months ago

Last modified 7 months ago

OOP architecture: MOD_member vs MOD_user

Reported by: lemon-head Assigned to: lemon-head (accepted)
Priority: major Milestone: unassigned
Component: FrameWork Version:
Keywords: Cc:
Follow up needed: none Frequently reported: 1
Announce on BW: 0

Description

  • A new module MOD_member to encapsulate member attributes and preferences from the database
  • Enhanced MOD_user module, to encapsulate user settings in the session

New MOD_member

provides access to DB tables:

  • members
  • memberspreferences, preferences
  • memberspublicprofiles
  • evtl rights

how to use:

  • use MOD_member::getMember_username($username) or MOD_member::getMember_userId($user_id) to get a member object
  • use the methods of this member object to read or write data from/to the DB tables.

Enhanced MOD_user

general:

  • represents the user with his session and current request, as opposed to a 'member account' in the database
  • if logged out, a user is associated with an ip address.
  • there is only ONE user in a request (-> hidden singleton)
  • all user settings in $_SESSION should happen in this module

logged in:

  • user is associated with a member account (-> MOD_member)
  • data from $_SESSION might be stored in the member account
  • data from the member account might go to the $_SESSION
  • MOD_user can ask MOD_member for settings stored in the member account

logged out:

  • user is associated with an ip address

Change History

02/09/08 14:35:32 changed by lemon-head

  • owner set to lemon-head.
  • status changed from new to assigned.

02/09/08 14:37:10 changed by lemon-head

What I forgot to say: * MOD_user::getMember() returns exactly the member object for the logged-in user (or zero, if not logged in)

02/10/08 17:07:46 changed by lemon-head

MOD_member uploaded in [4040].

(follow-up: ↓ 5 ) 02/10/08 21:08:42 changed by jeanyves

We definitively something like this

The problem is the transition, if we "cache" data for members in the session, we have the risk of updating them in the database and not in the sessions. It can create a mess. As a precaution I will suggess : 1) to have something in the session to tell that the session is out of date 2) to have something global to say that all session are to be refresh

Anyway, this is a subject to be continuated + the link between user member managed thru the getXXXX is a good idea too (but I will kill this user table, it will be no more than 3 fields in it before end of 2008 ;-) )

(in reply to: ↑ 4 ) 03/04/08 03:01:50 changed by micha

  • follow_up changed from none to test.
  • freq_reported set to 1.
  • show_on_bw changed.

I just activated the first version of MOD_member and make use of it in rox-based donation (/donate)

04/15/08 12:34:18 changed by micha

MOD_member is on production since rev. [4558]

04/15/08 12:34:25 changed by micha

  • follow_up changed from test to none.

04/15/08 12:34:32 changed by micha

  • milestone changed from unassigned to BigPicture.

04/23/08 11:50:39 changed by philipp

  • milestone changed from BigPicture to unassigned.

Milestone BigPicture? deleted

Trac Customization: trac stylesheet
SourceForge.net Logo