Ways of accomplishing "Remember this option".

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Ways of accomplishing "Remember this option".

Post by kaisellgren »

Hi there,

I've been recently coding a control panel, which contains loads of links, buttons, pages, etc. And since every user have their own individual preferences, needs, the way of thinking - I've decided to implement some sort of "remember this option" -feature.

Think about the following procedure:
1) Login
2) Click "Manage"
3) Click "Manage Articles"
4) Scroll down a bit
5) Click on the Article Name field
6) Type the article name
7) Press Tab to jump to field article text
8) Type the article

And in the end, set a number of settings like Date, Publisher, Category, etc again and again everytime the same details. So how would you implement a feature that remembers all these options, and what would be an ideal way to do this? I mean, just storing the latest settings? Or the ones that have been used most?

I was also thinking about improving the above procedure to something like:
1) Login (if cookies & session nonexpired => autologin = no login needed, this section is skipped)
2) Mouse hover Manage -> Click on the submenu Manage Articles (one click needed only)
3) Automatic JavaScript scroll to show the content user wants to see immediately
4) Auto select the Article name field

And the settings would be autoloaded to something by default and the Enter key would submit the form.

What are your opinions? What have you done for your project to make it more usable?
cptnwinky
Forum Commoner
Posts: 84
Joined: Sat Dec 27, 2008 10:58 am
Location: Williamstown, MA

Re: Ways of accomplishing "Remember this option".

Post by cptnwinky »

You could set a cookie with the values you want remembered or, even better, if the user is authenticated (in other words you know exactly who they are within the script) you can store the settings in a db table with the ID of the user who's settings your saving. Something like...

Table: RememberSettings
id, userid, settings
1, 3, option1,option2,option3,etc

Then, when that user returns you can pull those options from the db and parse them as you like performing conditional statements to achieve the desired affect.

Does that make sense?
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: Ways of accomplishing "Remember this option".

Post by kaisellgren »

cptnwinky wrote:You could set a cookie with the values you want remembered or, even better, if the user is authenticated (in other words you know exactly who they are within the script) you can store the settings in a db table with the ID of the user who's settings your saving. Something like...

Table: RememberSettings
id, userid, settings
1, 3, option1,option2,option3,etc

Then, when that user returns you can pull those options from the db and parse them as you like performing conditional statements to achieve the desired affect.

Does that make sense?
Yes of course that makes sense, but I was looking for a slightly more advanced, flexible and versatile solution though.
cptnwinky
Forum Commoner
Posts: 84
Joined: Sat Dec 27, 2008 10:58 am
Location: Williamstown, MA

Re: Ways of accomplishing "Remember this option".

Post by cptnwinky »

I'm not sure what you mean by more advanced, versatile, etc. The level of versatility really depends on how you've coded what you already have. If say, for instance, you were using smarty to separate your logic from display then using smarties built in conditionals would be elegant and versatile I suppose. If though, your php is littered with HTML then there really is no elegant way to do it.

I may just be misunderstanding what your getting at though.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Ways of accomplishing "Remember this option".

Post by alex.barylski »

The way I do it is have an INI file associated with each user account, and when the user logs in, I initialize a config object which holds all the settings for that specific user.

INI's are easy to modify and provide excellent facility for such a task.

The only downside is the file permissions required when you want to save changes to the file, but that of course depends on the system setup.
cptnwinky
Forum Commoner
Posts: 84
Joined: Sat Dec 27, 2008 10:58 am
Location: Williamstown, MA

Re: Ways of accomplishing "Remember this option".

Post by cptnwinky »

I would think then that storing these options to remember in the users INI file would be the way to go. Either way, when storing user data in a world writable INI file, any solution you come up with is not going to be elegant perse.
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: Ways of accomplishing "Remember this option".

Post by kaisellgren »

I will definetly store the settings in a database. But I'm wondering about the whole system. There are hundreds of different forms with totally random different fields and fieldtypes (radio, checkbox, textarea, etc) and it must be all automatic that means I am not going to hard-code a remembering system for all forms individually -- they must fully fluid, working, automatic and extensible. Also settings for the remembering will be provided, such as if the user wants to remember certain things or not in certain forms or in certain form fields. I'm gonna grab some pen and paper :P
cptnwinky
Forum Commoner
Posts: 84
Joined: Sat Dec 27, 2008 10:58 am
Location: Williamstown, MA

Re: Ways of accomplishing "Remember this option".

Post by cptnwinky »

Ah, I had no clue there were random form fields. That does make things tricky. I'm guessing then the solution will lie with whatever routine your using to generate these random form fields. Could you post any code or explain to me how these fields are generated and what the expected results should be.

I'm kind of confused as well if a form field is randomly generated on a page load will the user never have the same form fields infront of them? Some background on the project your working on would help immensely.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Ways of accomplishing "Remember this option".

Post by alex.barylski »

I would think then that storing these options to remember in the users INI file would be the way to go. Either way, when storing user data in a world writable INI file, any solution you come up with is not going to be elegant perse.
Why wouldn't it be elegant? Second, define elegant. Personally I find serializing an config object as an INI file a very flexible, easy to understand solution.

Long winded SQL statements are much harder to maintain, unless you use a data mapper of some sort, in which case you would achive the same effect, only an INI file is more portable and can be edited quickly using a text editor and not require using phpMyAdmin, etc.

INI doesn't have to be world writable, but some systems require it sure. Then again, I don't store INI files or any files except application assets in publically accessible directories, usually.

I don't think storage medium is much of an issue, so much as the config object and it's ease of use.
I will definetly store the settings in a database. But I'm wondering about the whole system. There are hundreds of different forms with totally random different fields and fieldtypes (radio, checkbox, textarea, etc) and it must be all automatic that means I am not going to hard-code a remembering system for all forms individually -- they must fully fluid, working, automatic and extensible. Also settings for the remembering will be provided, such as if the user wants to remember certain things or not in certain forms or in certain form fields.
Ok so your using a database. The only problem I have with a database for things like this, is settings tend to come and go, and each time you add or remove a setting from the source, the DB schema needs to be updated, PITA. Editing an INI file is much easier. That being said, you could express the schema using arbitrary name=value fields:

Code: Select all

config_table:
pkid, user_id, name, value
Now each user can have a variable number of parameters associated with their account, the problem being, 'value' is not flexible, it's either a TEXT, INT or VARCHAR, etc.

So you have to deterine what kind of data you are going to store. Images? Then you need a blob or a more flexible solution such as using multiple tables like above.

I'm not sure I understand what you mean by fully automated.

What kind of data are we talking here? Form data?

Approach it like any other table, the interesting part is figuring out a way to include that data on each request if it is indeed configuration data. Secondly, you have determine what data is going to be stored. Configuration data is not best stored in a DB, especially when it's the user/pass/port/name of the database you are connecting to. :P

For that reason I suggest keeping config data in a INI file or some external source that is always available.

I hear "remember this option" and I think:

1. Window positions/dimensions of an AJAX window
2. Whether to show popups
3. Last visited tabs, etc

Cheers,
Alex
cptnwinky
Forum Commoner
Posts: 84
Joined: Sat Dec 27, 2008 10:58 am
Location: Williamstown, MA

Re: Ways of accomplishing "Remember this option".

Post by cptnwinky »

Why wouldn't it be elegant? Second, define elegant.
I'm curious myself what the op meant by elegant. In this case I think a flat file wouldn't be elegant because the more settings that are stored in the INI files the more memory and processing power will be used to find specific settings in it (remember the op is already using individual INI files for each user, who knows how many settings are already stored in it). Having to read the contents of the entire file into memory for a handful of settings to me seems sloppy. Especially when the same could be done with a lot less fuss by, "SELECT setting1,setting2 FROM settings_table WHERE userid = ?". Now you have an result without unnecessary stuff to parse.
The only problem I have with a database for things like this, is settings tend to come and go, and each time you add or remove a setting from the source, the DB schema needs to be updated, PITA.
Why would the schema of the database need to be updated? All you would do is be working on a specific row that correlates with the settings of a specific user. Just as you mentioned in your config_table. Also, why would a setting be stored as an image? Where do you get that the configuration data would be the user/pass/port/name of the database your connecting too; this would be ridiculous to store in a database since you would need those values to retrieve those values. Clearly whats being stored is data that will assist in making elements on a page persistent, not db connection info. I think your just nitpicking here and trying to find reasons to justify your stance.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Ways of accomplishing "Remember this option".

Post by alex.barylski »

I'm curious myself what the op meant by elegant. In this case I think a flat file wouldn't be elegant because the more settings that are stored in the INI files the more memory and processing power will be used to find specific settings in it (remember the op is already using individual INI files for each user, who knows how many settings are already stored in it).
I think your getting OP confused with me. :P

Anyways...I really dought that INI files are more demanding on the server than a DB. Yes INI files need to be parsed each request (this is very fast) and the memory...well remember he needs access to these variables at some point so he either fetches them one at a time from the DB (which would be sloooow) or he pulls them into variables/objects anyways, so what difference does it make whether the data originated from a database or INI file?
Having to read the contents of the entire file into memory for a handful of settings to me seems sloppy. Especially when the same could be done with a lot less fuss by, "SELECT setting1,setting2 FROM settings_table WHERE userid = ?". Now you have an result without unnecessary stuff to parse.
Sloppy? Why?

Seems to me, that keeping settings in a INI file (which is what the INI file is intended to do -- RDBMS are designed to store relational data, not configuration data) would make most sense. Considering the application depends on the settings data to initialize itself, if a DB connection failed, your application would just flat out crash. At least if the application can initialize itself, it might have the common sense at that point to display a friendly error and maybe email/notify the admin of a downed database.

Pulling in configuration data using a single SELECT is easy enough, but what happens when a setting gets added or removed? Now you need to update the INSERT/UPDATE queries to reflect the new schema -- PITA.
Why would the schema of the database need to be updated? All you would do is be working on a specific row that correlates with the settings of a specific user
Because if your settings are, for example:

Code: Select all

show_popups, enable_mailing, notify_admin_on_failure, last_selected_tab, etc
Then one day you decide to add a field or remove a field (ie: setting)...you either have ot update the INSERT/UPDATE queries or using phpMyAdmin to add the fields. Manipulating an INI file is much easier.
Also, why would a setting be stored as an image
No idea, I'm not entirely sure what OP is after...whether it's a 1:1 automated storage solution of form data to a data table or whether he's storing application configuration data, like I have shown above.

If he was after a FORM solution that it's possible a user might upload a photo, which would require a BLOB field type and thus no longer work keeping it in the datbase.
Where do you get that the configuration data would be the user/pass/port/name of the database your connecting too; this would be ridiculous to store in a database since you would need those values to retrieve those values.
That was my point exactly. It's important to determine what kind of data he is going to store. Configuration data doesn't really fit well in a database for that reason. Database, SMTP, IMAP, etc...all require authentication, configuration details...much like file paths or whatever. Keeping those details in the database means if the database doesn't work, the application doesn't work. Granted most apps rely heavily on DB's for data storage/retreival but no one system should ever be responsible for catastphoic failure -- every engineering discipline follows that principle, programming should be no different.
Clearly whats being stored is data that will assist in making elements on a page persistent, not db connection info. I think your just nitpicking here and trying to find reasons to justify your stance.
What stance? What nitpicking? Yes I nitpick, thats the point of coming to a forum, uncover every rock, being pedantic.

I'm simply saying that configuration data doesn't belong in a database. While there are instances where it might make sense (such as a supporting multiple application installations with a single physical install) for the most part, I think it's good practice to keep config data out of the database. Perhaps you are just offended because you keep config data in a database table? :P

Seriously though, I'm not clear on "what" exactly the OP is storing in a table...form "data" is not configuration settings...it's "data" and does belong in the DB.

If he is persisting the users environment, so the application returns to exepcted state on next visit, that is not database data, it's registry data or configuration data.

Windows has the registry which superceeded the INI file but the principle is the same.

Ultimately the choice is the OP's whether he uses DB or XML or SHMOP, it's irrelvent to the end result but keeping data properly organized in domain specific data stores will help keep your code clean and organized and ultimately make your application better, IMHO.

Cheers,
Alex
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Ways of accomplishing "Remember this option".

Post by josh »

EAV
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Ways of accomplishing "Remember this option".

Post by alex.barylski »

EAV...I wasn't aware of a formal definition, but it sounds like what I described above. Interesting, thanks for the heads up. :)
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Ways of accomplishing "Remember this option".

Post by josh »

<3 formalisms
kai__
Forum Newbie
Posts: 1
Joined: Thu Jan 08, 2009 1:49 am

Re: Ways of accomplishing "Remember this option".

Post by kai__ »

In general if a user wants any pages he/she visits to remember any form data he/she enters, they would install a plugin for their browser to remember the information.

Most users today have such a plugin installed.
Post Reply