I can't think of any strictly HTML/CSS ways of doing this, anything I can think of requires, PHP, JSP, ASP, CFM or some other dynamic driven website. It is very easy to use any of these languages and still not need a database, but it is not possible with just pure HTML, or CSS. It might be possible with JavaScript but I really doubt it.

As far as the cookies go, that wouldn't work, because cookies are sent to the user from the server (with the understanding that the end user is not supposed to be able to modify the contents of them).

If this can be done with ASP.NEt then that would be great if i can get some help with that, I need this forum is for HTML and if it needs to be moved to the ASP.NET forum for help then a mod or admin please do so, thanks.

ps thanks for the reply.

You can set cookies anytime using JavaScript. you can even set a cookie and read the value straight back...

But you can't (shouldn't) use JavaScript and can't (just can't) use cookies to update huge sections of pages. Usually the complexity of what you're trying to make dynamic will influence your decision... For products a database is probably a good idea... that or XML and some XSLT... >_>.. damn, I've gotta stop advocating XSLT... feels like I do it at least twice a week.

Try and classify every aspect of the products in question, then figure out the best way of representing those objects.. then figure out whether to generate pages when they are requested or generate pages when things change... most "dynamic" sites do a bit of both.

This is all very conceptual airy speek: you'll need a working knowledge of at least one server side programming language or methodology... if you have used ASP you'll no doubt find it easier to stick with that.

A few general tips:

- The way to get data from users is via forms (ignoring Javascript methods)
- You have to collect form data in a script
- Things only exist if you create them
- You should check very carefully what people send to a script in any language, ASP is probably safer than languages like Perl and PHP., but, even if the users of a system are all "trusted", you don't want careless mistakes to render a site useless.
- Do as little processing as possible.. it's better to have the owner of the site "wait" a while while their changes are set in stone, than have all users of the site wait while a script "remembers" alot of owner choices and slowly pieces them into a page.

your question itself is a very vague one. even with a programming language selected, there's alot of choices that are up to you... there's no standard way to do anything.

I see what you are saying, what i was saying was only one page of the site needs to be changed dynamically which is the special offers page, only the site owner can do this, my first idea was to have a secret form which allows to upload pictures and information to the special offers page, but i dont know how i could do this, and also it got me little confused when i was told that cookies could be a option.

well. you'll also need a way of maintaining "state", that is, keeping track of what a person has been doing and usually whether they are allowed to do something else.

one of the more standard ways of knowing who a user is involves setting a cookie for that user:

- providing the user with a log in form.
- in a script; checking the users name and password (for one user thats easy), then writing a random value in a cookie to the user, that represents a "session".
- every time the user tries to do something, check if that random value in their cookie is the correct one. the more frequently you change the value, the more secure the site is.

a "secret form" is just asking for trouble =P... the amount of hackers out there looking for vulnerabilities in sites is thankfully quite tiny.. but they are there, apparently.

there are other ways of authentication; in fact ASP provides a whole set of tools for doing it (mostly cookie based). I don't write ASP so I can't really help you with specifics...

the simplest authentication is asking the owner to provide their password EVERY TIME they try to make a change. if changes are rare, this isn't too much of a problem.

I can do that but only my only trouble is i need a guide into how the user can change the items listed on the page without editing the site via frontpage and without using the database.

An irrelevant example
Look at this forum. It has lots of pages, and they're all dynamic. look at a single post. for a few hours you're allowed to edit your post. I won't claim to know exactly what's going on behind the scenes; but: the scripting language used here is PHP. I imagine that an SQL or similar database is used to store data. The data in the database is split into tables, rows, and cells. Lets assume this topic occupies a table, each post occupies a row, and a row contains, a message column, a date column and a userid column.

When i make a post, a PHP script reads in my post, derives my userid and the date, connects to the database, and writes a row (if i made a reply) or a table (if i made a topic). then, it rebuilds the HTML page for this topic (post285696.html). A rebuild involves acquiring all neccessary values from the database, and saving them in an HTML page along with HTML code. The headers, footers, sidebars, adverts etc are added in that stage (the forum index are also rebuilt at this point). As a user, I don't see that happening, I just see a new topic on a page, and a link in the forum, and I'm happy.

So, why not just write a HTML page? why bother writing to a database atall?
If the only record of my topic is an HTML file, the only way to change my post or add replies to it is to: read in the HTML file, search for structural "hints" that exist in the HTML markup, and then overwrite or append values. Now, I promise that's a hell of a long process, and it's very, very likely to result in screwed up pages, lost or corrupt data, et cetera.

A database doesn't have to be an SQL connect-query structure,
If you replace tables with folders, rows with folders, and cells with individual files: you still have a database. The folders and files you use need to follow a naming convention, and you need to establish your own protocol for "connecting" and "querying". The more simple a thing you want to do, the more simple your structure will be; but the hardest part is figuring out your initial protocol, and getting a reusable script created. Once you have that, your site will, by nature, manage itself.

NOT a tutorial =P
Now I could Google the ASP functions for capturing data from a posted form, writing to a text file, reading from a text file, and creating folders. That's the list of things you need to do: if you want to go without databases and use ASP. The last person I talked to about ASP said they hated it.

If you don't know much ASP, consider PHP. It's free and easy to learn. The type of functions you need will be the same, and the order of functions will be the same. I don't like PHP much, but, that's just my preference.

I love tutorials, but I like tutorials that demonstrate individual functions. A tutorial that tries to explain too much is just reading someone's well-annotated source code. The least you'll get out of it is a headache, the best you'll get is another persons solution to a problem that isn't quite the one you were looking to solve.

Dynamic Content Generation Design Questions
-What isn't going to change?
Things that aren't going to change are as important than things that are! The "feel" of the site isn't going to change whatever the owner wants to write in the product description or upload as a new image (* that's another subject, but it's easy in PHP, easy in Perl, and probably easy in ASP, and should be among the last of your concerns at this point). The layout of the page and product description will probably be consistant unless you want the user to provide the entire HTML for a page. Which is another method incidently. However, you're the web programmer; it's your job to make the process as simple to the user as possible, and as robust as possible.
-What is going to change?
Things that are going to change need to be provided via an input means, forms are ideally suited for plain text, and any kind of file (by upload), so that's pretty much everything. When that data is submitted, you need to save it in a way that the values in it can easily be read back, for rebuilding displayable pages, and for allowing the user to edit their submission without writing it all over again.
-When is it going to change?
In some circumstances, a page should be "rebuilt" everytime it is accessed. This is very rare! For the most part, you can rebuild pages when a change is made.
-Who can change it?
Already discussed.

A relevant example
Your site has a page that displays a single product. We'll call this "special.html". A product comprises of a title, a description, an image and a price, and a unique product ID. This page is plain HTML (it is NOT dynamic).

Initial Input
Your owner opens another page (That is not hyperlinked from anywhere). This page contains a form that allows the owner to create a new product (with a unique id, a title, a description, and a picture). The owner submits the form*.

*The form could contain a password field. Even if someone inadverantly stumbles upon the page and decides to mess about, your script can check the password... which leads to:

Form Processing
The code that recieves the form ((ASP or otherwise) reads the form data, checks that it is ok, outputs a file called title.txt, that contains ONLY the title, outputs a file called description.txt that contains only the description, and outputs the image file, calling it product.jpg (lets assume only jpgs are allowed). The script then recreates the page "special.html", inserting the new product into the page. You don't even need to read the text files at this point. But you do need to open "special.html" as if it were a text file, and write updated data into it.

Editing
The owner changes their mind and wants to change the item. You have another file called edit.asp, the asp code in this form reads those text files you stored eariler, and populates a form with the values. The action (target/handler) for that form is the same script that you used to save the original version of the file*. The circle is complete, and your page is manageable by a user rather than by a web programmer alone.

* (and maybe edit.asp is the same file you used to write the original product) ^_-

Simple example finished. Say; you want more items, those unique product codes will come in handy...

Hope that helps some; I had to work out alot of stuff for myself; and I don't have a wealth of example code, Google is a good tool, but look for the solutions to the individual problems that make up a bigger problem, and your search will be more fruitful.

In the past, because I have no server-side coding experience, I have created the page template and then used an external javascript for the client to update his product specials.

This is not the best way...but it is the easiest. I simply showed the client how to modify the javascript in notepad.