Opened 11 years ago

Closed 9 years ago

Last modified 6 years ago

#396 closed new feature (wontfix)

OOP architecture: MOD_member vs MOD_user

Reported by: lemon-head Owned by: lemon-head
Priority: major Milestone: Legacy Resolved
Component: FrameWork Keywords:
Cc:

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 (11)

comment:1 Changed 11 years ago by lemon-head

  • Owner set to lemon-head
  • Status changed from new to assigned

comment:2 Changed 11 years ago 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)

comment:3 Changed 11 years ago by lemon-head

MOD_member uploaded in [4040].

comment:4 follow-up: Changed 11 years ago 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 ;-) )

comment:5 in reply to: ↑ 4 Changed 11 years ago by micha

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

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

comment:6 Changed 11 years ago by micha

MOD_member is on production since rev. [4558]

comment:7 Changed 11 years ago by micha

  • follow_up changed from test to none

comment:8 Changed 11 years ago by micha

  • Milestone changed from unassigned to BigPicture

comment:9 Changed 11 years ago by philipp

  • Milestone changed from BigPicture to unassigned

Milestone BigPicture? deleted

comment:10 Changed 9 years ago by fake51

  • Resolution set to wontfix
  • Status changed from assigned to closed

Architechture has changed, we're moving away from modules

comment:11 Changed 6 years ago by TimLoal

  • Milestone changed from unassigned to Legacy Resolved
Note: See TracTickets for help on using tickets.