Re: Help with extending HTML_QuickForm_select

On Monday 07 February 2005 04:34 pm, you wrote: > >>Ian Eure wrote: > > > > On Monday 07 February 2005 02:03 pm, Jamie Alessio wrote: > >>I took Justin's idea and updated my code to use a hidden multi-select > >>that gets updated via javascript on the onClick event of the button that > >>actually moves the elements on the page for the user. It took me some > >>time and off-list explanation to figure out that by "hidden > >>multi-select" Justin meant an actual <select> element that has is hidden > >>from the user via a "hidden" style attribute and is not a <input > >>type="hidden"> form element. Once I got that straightened out the rest > >>made sense and I was able to accomplish the same goal without relying on > >>the onSubmit form attribute which is a much better solution. > > > > I would suggest that you implement some mechanism for a graceful > > degradation for non-javascript browsers. For example, if you have an init > > function which sets up the scripted controls and hides the 'real' > > multiselect. > > > > In this way, non-javascript browsers only see a multi select which they > > can still use, while js-enabled browsers get the more sophisticated > > control. > > What type of 'init function' are you suggesting? A PHP init function? A > javascript init function? The only thing coming to mind is something > like using the javascript onLoad event to call an init function but I > don't think using that is realistic from a class within HTML_QuickForm > since I'd need access to the <body> tag of the page that contains the > form. I'd love to be wrong on this so please clarify what you are > suggesting. > Certainly. I'm referring to a JavaScript initialization function which would: 1. Hide the real multiple select control. 2. Create the scripted control(s), buttons for interacting with them, etc. So your markup would be just the same as if you had a regular multiple select, and everything else would be handled by the script's initialization function. In this way, non-scripted browsers just see a regular multi-select, but script-enabled browsers hide that and create the enhanced controls to work with. Make sense? > I agree that it would be nice to have graceful degradation for > non-javascript browsers, but I'm not sure how to accomplish that from a > subclass of HTML_QuickForm. I'm thinking that it might be up to the code > creating the form to establish whether form elements that require > javascript should be included or not. From what I can tell, the other > QuickForm types that require javascript (like 'hierselect') don't have > any sort of degradation and don't do any sort of checking to see if > javascript is enabled. Perhaps this problem has been kicked around the > list in the past? I'm all for putting some sort of graceful degradation > in place but nothing is coming to mind on how to accomplish this so I'd > like to hear your ideas on it. Thanks. > As far as I know, the hierselect stuff is not readily implementable without breaking things out to a multi-page form. This is obviously not practical, whereas your proposed control is imlpemented as an enhanced UI on top of an existing control.

Attachment: [application/pgp-signature]