in reply to Javascript: Display Logic or Business Logic?
suaveant++
You should never rely on JavaScript to validate data from the end user, as it is too easy a hacker to disable or modify your JavaScript so that invalid data gets sent to the server. Also if you rely on JavaScript validation then you lock out users who have disabled JS, or don't have support for it in their browsers (eg. phones)
There is nothing wrong with doing client side validation to help the end user (eg, highlight empty form fields in red), but any client side validation must be duplicated on the server as well.
Given all that, I don't think JavaScript can form part of your business logic, it can only ever be part of your display logic.
I take your suggestion about using contemplating to generate JS, and I can see it might make sense for validation. For example suppose you have a list of valid values for a field. Rather than hard code the list into the validation logic in both perl on the server, and JS on the client, and attempt to keep them in sync, you could store it in the database, and then generate the validation JS code on the fly.
An alternative approach (that I have used in the past), is to store it once in the JS validation code, and then write some perl to parse the JS and extract the list of valid values. This was rather fragile, but it avoided maintaining two lists.