Bill D., Three things I'm trying to accomplish: 1. I do not want to have 5 different but similar forms for this 2. I do not want to have 5 different update commands for the form(s). 3. I do not want to have 30+ complicated <@IF> expressions to determine field by field if it should be an <input> or text value. Because both I'm lazy and it would require more server processing then my approach.
One form, one update statement, very little logic. It's for an internal application, with logs and a lot of other stuff to prevent fraud. The hidden fields do not play a roll. Am I nuts? Chuck Lockwood ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ LockData Technologies, Inc. 309 Main Avenue, Hawley, Pa 18428 570-226-7340 ~ Fax: 570-226-7341 [EMAIL PROTECTED] ~ www.lockdata.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: Bill Downall [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 13, 2005 5:20 PM To: [email protected] Subject: Re: Witango-Talk: Disabling form fields Chuck, I agree with Bill C. I do the same sort of thing as you server-side, within Witango <@IF> expressions. If it's the kind of login that you would disable a field for, I just show the value as plain html text. If it's the kind of login that allows editing or updating, I show the form input field. But I don't put anything I don't need to in the html, even as a "hidden" field. I do a lot of right-click/"view page source" myself to figure out how other people do things. I assume other people do to my sites, too. Bill Conlon wrote: > I can understand having a client side calculator to help the users, and > avoid a round trip to the server for updating the totalcharge. But > nothing that's submitted can be trusted, and the Total Charge must be > calculated at the server, so what's the point of having it as a hidden > field? > > I could submit any arbitrary POST, for example, changing: > > <INPUT NAME="TotalCharge" TYPE=HIDDEN Value=173.50> > > to > > <INPUT NAME="TotalCharge" TYPE=HIDDEN Value=0.00> > > or for that matter issuing myself a credit? > > So the hidden and blurred fields are for user convenience, but really > shouldn't be part on any update/insert actions. > > > On Wednesday, July 13, 2005, at 01:30 PM, Chuck Lockwood wrote: > >> Thanks to all that replied, I'm going to use Mike's suggestion >> though. Had >> to add a style to gray out the field because READONLY doesn't do it like >> DISABLE does. And I'm still having problems getting the <SELECT> tags >> disabled, nothing seems to work, onFocus=blur() or READONLY=true! >> >> A posted a sample of the form here: >> http://www.lockdata.com/testing/readonly.tml (It's stripped down so >> it will >> not post or anything.) >> >> If you're interested on how it works, see the notes below. >> >> What you don't see by looking at the page is the server side setup, >> which >> I'll outline below. >> >> Each field is assigned to one of 5 privilege level groups and contains a >> @@request$EM# variable, where # is the group that field belongs to, >> as shown >> below: >> >> <TEXTAREA NAME="Orders_InternalNotes" ROWS=3 COLS=60 WRAP=VIRTUAL >> @@request$EM1><@COLUMN "Orders.InternalNotes"></TEXTAREA> >> >> <INPUT NAME="Orders_PassengerName" TYPE=TEXT SIZE=30 MAXLENGTH=60 >> VALUE="<@COLUMN "Orders.PassengerName">" @@request$EM2> >> >> <INPUT NAME="Transactions_RegularPrice" TYPE=TEXT SIZE=10 MAXLENGTH=30 >> VALUE="<@COLUMN "Transactions.RegularPrice">" @@request$EM5> >> >> A loop at the top of the page sets the value of the request$EM# >> variables >> >> <@FOR START=@@request$EMode STOP=5> >> <@ASSIGN request$EM<@CURROW> VALUE='READONLY=<@DQ>true<@DQ> >> Class=<@DQ>GrayOut<@DQ>'> >> </@FOR> >> >> So the variable is empty if the privilege level is equal or higher >> and has >> no effect on the field tag. That's the key! >> >> I set the @@request$EMode as so: >> >> <@IF EXPR='@@User$vUserPriv[1,M] < 25'> >> <@ASSIGN request$EMode VALUE="0"> >> <@ELSEIF EXPR='@@User$vUserPriv[1,M] <30'> >> <@ASSIGN request$EMode VALUE="1"> >> <@ELSEIF EXPR='@@User$vUserPriv[1,M] < 35'> >> <@ASSIGN request$EMode VALUE="2"> >> <@ELSEIF EXPR='@@User$vUserPriv[1,M] < 40'> >> <@ASSIGN request$EMode VALUE="3"> >> <@ELSEIF EXPR='@@User$vUserPriv[1,M] < 45'> >> <@ASSIGN request$EMode VALUE="4"> >> <@ELSEIF EXPR='@@User$vUserPriv[1,M] < 75'> >> <@ASSIGN request$EMode VALUE="5"> >> </@IF> >> >> Simple and straight forward, if I can get the <SELECTS> disabled! >> >> Chuck Lockwood >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> LockData Technologies, Inc. >> 309 Main Avenue, Hawley, Pa 18428 >> 570-226-7340 ~ Fax: 570-226-7341 >> [EMAIL PROTECTED] ~ www.lockdata.com >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> >> -----Original Message----- >> From: Willochell, Mike [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, July 12, 2005 8:27 PM >> To: [email protected] >> Subject: RE: Witango-Talk: Disabling form fields >> >> Chuck, >> >> >> >> Try READONLY=TRUE. >> >> >> >> Mike >> >> >> >> ________________________________ >> >> From: Chuck Lockwood [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, July 12, 2005 7:58 PM >> To: WiTango-Talk >> Subject: Witango-Talk: Disabling form fields >> >> >> >> What is the easiest, safest, most reliable way to disable editing of >> selected form fields based on privilege levels or other criteria. >> >> >> >> I have used onfocus=blur() in the past, but was hoping to use >> disabled=true now. I find it displays the fields grayed out which is >> great, but doesn't include them as arguments, which is not good. >> >> >> >> What other solutions are there for always displaying the data but >> restricting edits on various fields without messing up the existing >> update action? >> >> Chuck Lockwood >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> LockData Technologies, Inc. >> 309 Main Avenue, Hawley, Pa 18428 >> 570-226-7340 ~ Fax: 570-226-7341 >> [EMAIL PROTECTED] ~ www.lockdata.com >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> >> >> >> >> _______________________________________________________________________ _ >> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >> _______________________________________________________________________ _ >> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >> >> >> >> >> _______________________________________________________________________ _ >> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >> > > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
