Topic: Temporary messages

[ober]

I have an idea of how it should be done, but I'm curious if there is actually a best practice.  My goal is to present messages like upcoming maintenance but have the user be able to kill those messages off if they don't want to see them.  My assumption is that most people use cookies for this. 

1) The application posts the message with a specific ID. 
2) If the user kills the message a cookie is created with that ID and a lifespan that goes just beyond the end of the event associated with the message.
3) If the user clears the cookie before the event ends the message reappears in the application.
4) And obviously when the event is over the message isn't displayed and eventually the cookie disappears.

Is that how it normally works?  Is there a better way?  The only other way I can think of involves database details but that would require setup and cleanup activities to keep things tidy.

[Mike]

I'm not a fan of using cookies to hid things like this since I assume people will access the site from multiple devices and be annoyed by the reappearance.  For something like this I'd look at using redis sets and setting the expiration time on the first creation.  Then you don't have to worry about cleanup nor SQL tables.

[micah]

Thats sounds like what I've done in the past. It depends on the message and its importance though.  Sometimes I just set a session value so the message doesn't appear again while on the site during the current session.  If there's a login to the site, you could store their choice in the database assigned to their user ID.

[ober]

*does a little reading*

I get it, I just don't see a huge advantage of this over simply storing a preference in the database.  The only advantage I see is the default ability to set a timeout on those items.