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'm with you except for the part of how and when you propose actually calling the javascript initialization function. I'm not grasping how to fit this in with HTML_QuickForm. Any chance you could provide an example of how this might be implemented?
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.
s 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.
The HTML_QuickForm_hierselect class can be created on a single page form, but requires javascript in order to work. See http://pear.php.net/manual/en/package.html.html-quickform.html-quickform-hierselect.php for an example. This isn't necessarily relevant to this discussion - I was just pointing out that there are other form elements that are part of HTML_QuickForm that require javascript and don't do anything helpful in the event that javascript is not available in the browser. That leads me to think that maybe someone already went through this and decided it's not practical to handle that sort of thing from a subclass of HTML_QuickForm, but that's a total guess by me at that point.
Thanks for helping me think this through.
- Jamie