Peter J. Farrell wrote:
Martin Heiden wrote:
Do it on the serverside!!!
Maybe I'm a cycle head, but it seems silly to use computation cycles
(although very little) to compute a year that changes only once per
year. Use a server side include or hard code it in your footer
template and remember to change it in the new year. Guess this is my
enterprise application architecture brain talking here.
.Peter
To me the real problem with this example is that by entering the
copyright year into the document using JavaScript, you are letting the
user decide which year your document is copyrighted in.
If the user's machine time is not set correctly, your copyright date
will reflect whatever year the time is set to. I realize that very few
people have their clocks set so far off that this will be a major
problem, but, it is important to keep in mind that JavaScript is a
client side language and you need to be aware that changes in the client
machine's environment will affect the document they see when you are
using JavaScript to generate content based on the user environment.
For things like copyright notices, I agree with Peter that they should
be generated server side, or hard coded into the page. However, I think
the point of Bob's example, is to ask the question: "How should I write
the JavaScript if I have an item in one or more pages that changes
dynamically with time or with each page load?"
I think Lachlans answer is that strict separation of behavior and
content creates a better structure for the page that is easier to create
and maintain. I personally feel that moving a single line of JavaScript
to a separate file is pushing this paradigm too far. However, putting a
single line of JavaScript in every link on a page would have the same
effect as in-lining all your CSS. If you ever have to make a change to
the page, you will be searching through the content to find all those
single JavaScript line rather than looking in one file for a place to
change them.
Carl.
******************************************************
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
******************************************************
