Controller + Model vs Ultra-slim controller that barely does anything + Library

Thanks for your answer!

There are lots of different ways you can do this. I would do this:

First you need at least two tables, one for actions, and then one for action_log

Code:

actions
-------
 action_id        
 action_name    // ie logout, login, not allowed, whatever
 action_code    // for convenience so logout = LO, login=LI etc (unique)

action log
----------
 log_id
 log_action_id
 log_date
 log_user_id

Then a library for logging actions. Something to use like this:

PHP Code:

public function log_action($action_code, $user_id) {
   ....
} 


Yup, this is pretty much what I have right now (+ A little bit of action specific data)

Also, since I want the "Action" part of the system be independent of the notification part, I'm not entirely sure if a "Type"/"actions" table would even make sense... I mean, sure, it stores all types of actions, but if I only have the name of the type then there's no real point in having a table for that. Same problem with my own code right now, though.

As for redirects or flash messages or how you deal with a certain circumstance, that is entirely separate from the action logs and should not be part of the action logging. I would autoload the action library, and then you are free to call it from wherever you need to.

Yes, this is what I want to achieve. Redirects shouldn't have anything to do with it and simply be called by the controller itself, but I want the notification (Not *only* flash messages, as described in my post above) part to rely on the action part without the action part having to depend on the notification part.

But if you really want to directly couple it together, you could add a column or two to the action table, one to indicate a logout url to implement a redirect, one to indicate a message field for a standard message to be returned.

Or, you can add to the library with a set method something like:

PHP Code:

$this->login_library->set_redirect('my/link');
$this->login_library->set_message('You are not allowed to do that.');
$this->login_library->log_action($action_code, $user_id); 


Or just put it into the call

PHP Code:

$this->login_library->log_action($action_code, $user_id, 'my/link', 'You are not allowed to do that.'); 


Actually this is exactly what I want to avoid. While the notification part can and should depend on the action part, it should really not be the other way around - Meaning that I want to get rid of the "Message" fields I currently have in my ActionTypes table. I also do not want to code in the message in my code though: I like it much better in my database. Maybe I should remove the "actiontypes"/"actions" table altogether and instead use an "NotificationTypes" table that sets a message for each type of action?

It really all depends on your app design and how you are implementing your messages/notifications etc. For instance, in your common header file you might have a:

PHP Code:

<?php if (!empty($notification)) { ?>
   ... show notification html absolutely positioned on page at top right or something
<?php } ?>

And your action log would return a suitably formatted notification. You could even, in your actions table, indicate if an action should send a red error message, a blue info message, or a green success message, etc etc.

Yeah, exactly. But I'm simply not sure where exactly I should put those individual fields. In my old actiontypes table? In a new notificationtypes table? I just don't want to somehow repeat myself somewhere where it doesn't need to be repeated (Which is why I don't want to include the message in the code, for example, but only once in the database with placeholders for specific data)

PS In terms of guests, you can set the user_id to 0, which could, for example, return the notificatons as per normal but not log in the database the actions done.

Yeah, my usersystem has a constant variable $GUEST_ID which serves that purpose. The problem with my current notification system is that, for guests, notifications should only act as a simple flash message - Whereas for real users, it sometimes can act like a flash message, and sometimes like a persistent message. And I don't want to mix both everywhere in my code.

PPPS You definitely do not need an entire module for this. But if you are into HMVC, then I suppose you should do a notifications module rather than a library.

I do need a notifications controller though, so users are able to delete notifications. The question is: Should my controller act as a true module and do most of the job, excluding database querying by a mode, or should I simply forward the call to my library? Because in both cases, I will need a controller (For user related actions on notifications, like deleting. Actually, pretty much only deleting.), a library (Either the whole thing or simply the action system, which doesn't need user feedback), and a model (Or not, depending on wether I do everything in the library or not). Which is the question I've called "Main problem" in my post :/

PPPPS (Last one) - It does not matter how tiny a module or a library or a model is. It is about the right place to put it to keep your site consistently built. Even if a model has a single database call in it, if it serves for proper seperation of concerns, you should do it. It will almost certainly fill up later as other functions pop up as being needed. And even if not, it still makes sense to keep to whatever pattern you are using.

Yeah, but it's exactly that "dilemma" that puts me back to square one. I can't decide on what would be the best way to do it.

Thanks again for your answer!