Best method to retrieve site settings
Printed From: Web Wiz Forums
Category: General Discussion
Forum Name: Classic ASP Discussion
Forum Description: Discussion on Active Server Pages (Classic ASP).
URL: https://forums.webwiz.net/forum_posts.asp?TID=16378
Printed Date: 29 March 2026 at 7:01pm Software Version: Web Wiz Forums 12.08 - https://www.webwizforums.com
Topic: Best method to retrieve site settings
Posted By: theSCIENTIST
Subject: Best method to retrieve site settings
Date Posted: 29 August 2005 at 8:23pm
Hi guys,
I have another website to develope, this time the customer is quite demanding, he wants to be able to change everything from a webpage (all site sizes, fonts, paddings, spaces, colors, and the main information, the lot) this means all this settings will be in the database, I tried to suggest that this settings can also be in a asp, xml, css file, but he doesn't want any of that, he wants to login, go to admin and change the lot from there.
This means ofcourse, allot of database operations just to retreive all these settings, the way this is usually handled is on top of the header or some sort of commom page that gets all these, and this will be called time after time as a user browses around.
I won't be using application variables, I was thinking on using cookies to store all this data as it is retrieved the first time, then set a time stamp with the settings change condition, so if a user gets the settings first time, on all other pages he won't be calling the db again to get the settings, unless the admin changed anything, in which case the change condition will be set, and the user will re-get the settings again from the database. Is this viable at all?
I don't want the users to call the database to retrieve and fill hundres of variables for each page call.
What other methods are there to ease the load on this kind of thing?
------------- :: http://www.mylittlehost.com/ - www.mylittlehost.com
|
Replies:
Posted By: Gullanian
Date Posted: 29 August 2005 at 9:22pm
Well:
1) If they want to be able to have ultimate control over the
font-sizes, borders, padding etc, use CSS and show him how to change
stuff in it
2) If that's beyond him, then consider a config file with
constant values. Way way quicker than a DB, you can comment it
all and make it real easy to change stuff.
Your cookie idea is OK, but lots of users are cookiephobic. This
would make the site look rather strange probably as there are people
viewing all sites with cookies blocked completely.
Try explaining this to your client, it's going to cause more problems
than it's worth to tackle that task dynamically as you
illustrated. Plus, changing table paddings isn't going to be
something you will change on a day to day basis.
|
Posted By: dpyers
Date Posted: 30 August 2005 at 3:16am
Well, there's reasons why common web technologies/techniques are used
the way they are that are due to limitations of the web and of existing
browser technologies.
If your client insists on changing the way the web works, it may be
time to walk as neither he nor you will be happy with the result. It
won't be a either/or is happy situation. He'll always blame you for
not adding some capability that he figures is essential 2 years
from now.
I think you'll find that your options will be realistically limited to
page-level CMS and/or site-level template based solutions. You might
also want to google for "stylesheet generator".
I find that clients like InnovaStudio's WebCMS - http://www.innovastudio.com/webcms.asp - http://www.innovastudio.com/webcms.asp
It's template-based and not as admin heavy/confusing as something like
phpNuke. I've set it up for a couple of clients to allow editing of the
templates.
FrontPage may be a good solution. Sooner or later they'll get stuck or
break something regardless of how they edit. You can always point them
to a FP newsgroup or site instead of having to drop everything and work
late "fixing" your code for a client who sounds like a pisser.
-------------
Lead me not into temptation... I know the short cut, follow me.
|
Posted By: Phat
Date Posted: 30 August 2005 at 5:44am
Or give him a admin login that actually writes a CSS file using FSO. I
doubt he would actualy change it that often so when he makes a change
just use FSO to create a whole new CSS page.
Saves hitting the DB and all the cookie issues
Just an Idea...
------------- http://buildit.sitesell.com/sitebuildithome.html - Get a website that sells
|
Posted By: theSCIENTIST
Date Posted: 30 August 2005 at 6:29am
Thx guys,
The CSS part I figured, it will be coming from the DB and I will give him a textarea to edit it, after all this will just be another column in the DB nothing more.
All sitewide presentation settings will coming from this DB retrieved CSS column.
I will have a table just for site settings, but I don't want this table to be hit and called upon on every page, as anyone actually done anything similar to my cookie based solution? I mean in theory it should work, this table is read on first page view, all settings go to the user cookie, he then uses these settings from the cookie as he goes from page to page, unless a change to the settings is made, in which case the user has to re-get all settings again from DB, as I said in theory should work.
As for people being cookiephobic, well, I see no harm coming from cookies, there's the spy and tracking that can be done, users just have to clear their cookies at the end of each day, I see more harm coming from Javascript than from cookies, I will have a message saying [cookies needed...].
He wants his new page to be modular, so he can call me later to add more functionality to it, he's not selling anything from it, it's for his church somewhere in west London, but he wants all info to be edited online, no more FTPing stuff around, and it be user based, to allow user discussion.
I've done this guy last page 2/3 years ago, and I'm charging him this time £800 for this new page, is this a realistic price for the ammount of work?
And please also comment on the viability of my settings cache (cookie) idea?
------------- :: http://www.mylittlehost.com/ - www.mylittlehost.com
|
Posted By: ljamal
Date Posted: 30 August 2005 at 8:49pm
I think the best solution is a config file that is updated via FSO. That way a simple update to the file can add new variables and values are easily changed and updated. I've done this for several web sites and sicne the information is not changed on a regular basis it's much better than cookies or database driven solutions.
------------- L. Jamal Walton
http://www.ljamal.com/" rel="nofollow - L. Jamal Inc : Web/ Print Design and ASP Programming
|
Posted By: Gullanian
Date Posted: 31 August 2005 at 5:29am
At the end of the day, he's paying you. You have a responsibility
as the profesional to alert him to the setbacks of the solution he
wants, but if he still insists then do it. As long as you
explained the setbacks properly (and I recommend doing a paper copy so
you can point him back to it if it causes problems).
If he finds out he doesn't like it when you do it, more work for you!
|
Posted By: theSCIENTIST
Date Posted: 31 August 2005 at 11:07am
Thx guys, here's what I have to say:
ljamal wrote:
I think the best solution is a config file that is updated via FSO. That way a simple update to the file can add new variables and values are easily changed and updated. I've done this for several web sites and sicne the information is not changed on a regular basis it's much better than cookies or database driven solutions. |
Config file updated with FSO? What's the format of this file? Text file, with stuff like:
GlobalWidth=100%
Color=#FFFFFF
Font=Arial
...
And so on...
If not a Text file, would this be an XML file with similar stuff as above? Or even if this is not an XML file, is it an ASP file with consts? In either case this file as to be called over and over as the user goes from page to page, so the penalties are the same as if it is coming from the database, unless you cache it, like what I have suggested.
Please elaborate.
Gullanian wrote:
At the end of the day, he's paying you. You have a responsibility as the profesional to alert him to the setbacks of the solution he wants, but if he still insists then do it. As long as you explained the setbacks properly (and I recommend doing a paper copy so you can point him back to it if it causes problems).
If he finds out he doesn't like it when you do it, more work for you! |
Yeah, he's paying me, but I don't want his ideas to slow down my server, as that would affect all websites coming from it, not just his one, that's why I'm thinking to make him happy without causing performance issues to the whole server, and therefor that's why I came up with the cache idea, he gets what he wants, and I get a fast server at the end of the day, but I'm just not sure as to the viability of this cache idea, I can also put all settings in an XML file, and allow him to edit it easily, but then this file would have to be called, read, parsed to populate all variables with data, then assign all values to their place, all this on every file as the user moves along, I need some cache here, I'm just not happy with all the calling/processing per page visited.
Ideas please?
------------- :: http://www.mylittlehost.com/ - www.mylittlehost.com
|
Posted By: Gullanian
Date Posted: 31 August 2005 at 11:32am
|
I think the config file idea is best. Store values in constant
variables, and use FSO with your admin backend script to parse this
data and manipulate it.
|
Posted By: theSCIENTIST
Date Posted: 31 August 2005 at 11:56am
I uderstand what you are saying, getting a nice little asp file, include that on every page or on the header which itself will be included on every page, now that is fine, but this file will have to be read and processed everytime, as a user goes to the about page it reads and applies the config, then he goes to visit the contact page, the same happens, the user could be visiting hundreds of pages, and hunders of times this file has to be read and processed, not to mention the visited page itself, don't you think there's too much overhead there?
My server is set to use user HTTP compression that forces every dynamic page to be read and processed before it is sent out, due to the dynamic nature of the file, the same happens to all asp, shtml, ... by default, even with no HTTP compression, so the server will not be serving this config file from cache, and that's where the overhead will be coming from.
Say you have 100 asp pages, a user goes through all of them, the server will have to process 100 pages and generate HTML for all of them to send out, but hold on a second, you also have a config file included on all of them, so the server will have to process twice as much, 200 pages, when the user requested only 100 of them, that seams a heck of alot of overhead, there's got to be a better way.
------------- :: http://www.mylittlehost.com/ - www.mylittlehost.com
|
Posted By: theSCIENTIST
Date Posted: 31 August 2005 at 12:29pm
This is just to say I remembered something else, I just remembered that the including is done before any processing on the main file, so in the end only one file is processed.
Yep, I think a full of Consts include file could be the fastest way.
I would still like to hear more alternatives to this.
------------- :: http://www.mylittlehost.com/ - www.mylittlehost.com
|
|