RE: profiles.
Store the user profile in a cached query. Select * FROM User_Profile WHERE UserName = 'foo' and Password = 'blah' Since the SQL statement will vary with each user's login values, the CFQUERY can have the same name and the record sets will be distinct. Then you just have to associate each user profile with the parameters you use to maintain state. While it will look like you are running the query with each page request, you will in fact be pulling the user profile from RAM -- not the database. best, paul At 12:27 PM 11/12/00 -0800, you wrote: > > My question is this... > > > > I view this kind of data as user "profile" data stuff that will > > essentially never change except for a few times after the end user > > logs in. They may change what queries they'd like to see, but > > the rest of the data isn't going to change. What I was thinking > > was to store this user profile data in a tablethen when the > > end user logs in...this "state" or profile data is pulled up and > > then acted upon. Is there a better way to store this data somewhere... > > and cookies are NOT an option here. Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
RE: profiles.
If you cannot use cookies, then you have to maintain state by passing some sort of key between all URL calls and form fields which looks up the current user's "profile" in a database. This works fine, but it will slow down the system a little bit. Imagine having to call the database upon every page load - that may not seem like a big deal, but put a hundred people on it, and you'll notice. -- Mark Warrick Phone: (714) 547-5386 Efax.com Fax: (801) 730-7289 Personal Email: [EMAIL PROTECTED] Personal URL: http://www.warrick.net Business Email: [EMAIL PROTECTED] Business URL: http://www.fusioneers.com ICQ: 346566 -- > -Original Message- > From: miles [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, November 07, 2000 9:24 PM > To: CF-Talk > Subject: profiles. > > > Hi, > > I have an interesting intellectual problem that I need to > solvenot immediately, but sometime in the next three > months. I am about to roll out a new website for a client > and to be honest (the client is aware of this) that its a kluudge > at best...but it worksthey are happy...Im happy. Everyone > is happy. > > PROBLEM! > > Everyone is NOT happy...me being the one that is not happy. > The problem is that the site IS a kluudge. The reason its a > kluudge is best left to history. However in rethinking the site, > I have come up with a solution that will not only make the > site more operable, but easier to maintain in the long run > and that much easier to develop for in the future. > > What I am wanting to do is modulerize EVERYTHING... > and its not right now. And one of those modules is a user > module...this module will keep all types of user data, it will > save different user queries (prepackaged ones of course for > external users of the site, internal users get to create their own > dynamic queries), last time they logged in, what their page is > supposed to look like, who their internal advocates are (this is > a support website so we assign them a support advocate that > works with them directly through the life of their support contract) > and who their sales reps are/wereetc. stuff like that. > > My question is this... > > I view this kind of data as user "profile" data stuff that will > essentially never change except for a few times after the end user > logs in. They may change what queries they'd like to see, but > the rest of the data isn't going to change. What I was thinking > was to store this user profile data in a tablethen when the > end user logs in...this "state" or profile data is pulled up and > then acted upon. Is there a better way to store this data somewhere... > and cookies are NOT an option here. > > Sincerely, > > Miles. > -- > -- > Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ > Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists > or send a message with 'unsubscribe' in the body to > [EMAIL PROTECTED] Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebarRsts or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]
RE: profiles.
A database, either relational or LDAP, is the best place to store the information during off-line time. Upon login, the relevant bits should probably be copied to a structure, as a session variable. If cookies aren't an option, as in "can't be used", then you can pass the session/client id via the URL or FORM variables. Your bigger problem may be in convincing a client to pay more money for something that they see as working fine. A friend of mine had a client who refused to pay for such a conversion, flat to component based, despite the fact that he knew keeping the old architecture would cost him more in the long run. Steve -Original Message- From: miles [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 08, 2000 12:24 AM To: CF-Talk Subject: profiles. Hi, I have an interesting intellectual problem that I need to solvenot immediately, but sometime in the next three months. I am about to roll out a new website for a client and to be honest (the client is aware of this) that its a kluudge at best...but it worksthey are happy...Im happy. Everyone is happy. PROBLEM! Everyone is NOT happy...me being the one that is not happy. The problem is that the site IS a kluudge. The reason its a kluudge is best left to history. However in rethinking the site, I have come up with a solution that will not only make the site more operable, but easier to maintain in the long run and that much easier to develop for in the future. What I am wanting to do is modulerize EVERYTHING... and its not right now. And one of those modules is a user module...this module will keep all types of user data, it will save different user queries (prepackaged ones of course for external users of the site, internal users get to create their own dynamic queries), last time they logged in, what their page is supposed to look like, who their internal advocates are (this is a support website so we assign them a support advocate that works with them directly through the life of their support contract) and who their sales reps are/wereetc. stuff like that. My question is this... I view this kind of data as user "profile" data stuff that will essentially never change except for a few times after the end user logs in. They may change what queries they'd like to see, but the rest of the data isn't going to change. What I was thinking was to store this user profile data in a tablethen when the end user logs in...this "state" or profile data is pulled up and then acted upon. Is there a better way to store this data somewhere... and cookies are NOT an option here. Sincerely, Miles. Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED] Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message with 'unsubscribe' in the body to [EMAIL PROTECTED]