QuoteReplyTopic: Best method to retrieve site settings 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?
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.
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
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.
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.
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?
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.
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!
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.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum
Web Wiz is the trading name of Web Wiz Ltd. Company registration No. 05977755. Registered in England and Wales.
Registered office: Web Wiz Ltd, Unit 18, The Glenmore Centre, Fancy Road, Poole, Dorset, BH12 4FB, UK.
Prices exclude VAT at 20% unless otherwise stated. VAT No. GB988999105 - $, € prices shown as a guideline only.