Re: Help with extending HTML_QuickForm_select

On Monday 07 February 2005 05:19 pm, Jamie Alessio 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'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? > Take a look at this: http://www.websprockets.com/post/html_quickform-add-on-packages It's a script element I wrote for QF, which will help you out a lot in this case. So, what you want to do is trigger a JS function after your form is output. If you use the Script stuff I reference above, this happens automagically. So, you have a script like so: // Initialize a single advanced select control. // Takes the string ID of the regular multi-select as it's argument. function initAdvSelect(selectId) { // Hide the real multi-select. var select = document.getElementById(selectId); select.display = 'hidden'; // Create the advselect controls createAdvSelect(select); } function createAdvSelect(select) { // Clone the existing select. var newSelectLeft = select.clone(); var newSelectRight = document.createElement('select'); // Loop through newSelectLeft, move selected elements to newSelectRight // Create add/remove buttons & set up event handlers for them // Add elements to form } Stick all this in a <script/> element, then add another with: initAdvSelect('regularSelectId'); or whatever the id attr on the regular select element is. So script-enabled browsers hide the real select and have the controls the user will interact with generated by the script, so there's no clutter in the markup for browsers without scripting facilities. Non-JS browsers ignore the script elements, and only see a regular multi-select. Does that make sense? > >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. > > 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-hi >erselect.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. > Right, and I was just pointing out that those controls don't have any easy equivalent without scripting. To illustrate my point, this is how you'd have to implement both controls without any script support whatsoever: Your scripted multi-select: 1. Use a regular, non-scripted multi-select. A hierselect: 1. Load a page with the initial dataset for the first select. 2. Select option, submit. 3. Load intermediate page with data generated or affected by the previous selection. 4. Select new option, submit. 5. Repeat 3-4 for however many controls you have cascading 6. Submit to final form. This is my point - there's no practical way to have a hierselect gracefully degrade to something that can work with a non-JS browser, which explains why there's nothing to do that. This is not the case with your multiselect code, which is simply a script-enhanced normal multiselect control, which is why you should think about making it degrade gracefully. > Thanks for helping me think this through. > No problem.

Attachment: [application/pgp-signature]