Re: HTML_QuickForm and improved version of advmultselect component

On 6/1/05, Ian Eure <ieure@php.net> wrote: > On Wednesday 01 June 2005 05:30 pm, Justin Patrin wrote: > > On 6/1/05, Laurent Laville <pear@laurent-laville.org> wrote: > > > Hi all, > >> (snip) > > > I could then start a proposal if nobody is against this idea. > > > > I'd like to mention for everyone's benefit that this isn't a normal > > multi-select, it's two select boxes next to each other emulating a > > multi-select. > > > Thank you for that clarification. > > My concern is the same as the last time this came up; I think it needs to be > backwards-compatible with non-JS browsers. > "needs" is a strong word. Yes, allowing non-JS browsers to use elements is good but this is a *very* small percentage of browsers. Unfortunately JS got some bad press in the past (mostly due to insecure implementations) but JS is a *good* thing. It should be turned on and it should be used. However, that said, I allowing non-JS browsers to work is a decent idea. > The way to accomplish this is: > > - Send a regular multiple select control in the markup, with a class set so > you can identify it later. > - Use JavaScript to: > = Change the name of the original control to something else > = Create the second select element, giving it the correct name (the "old" > name of the element in the markup > = Create any necessary controls, buttons, etc. > = You'll also need a handler to set the "selected" attribute of everything > in the 2nd select element when the submit button is clicked. > This is good in theory, but how do you handle customization, such as custom layout? It could be a big pain to get this implemented well. > > Since the scripted element is functionally identical to the normal > multiple-select, it seems like a bad idea to make it incompatible with older > browsers. > > I'd be glad to work on the JS end of things if help is needed. > Sure, if you can get it working that would be great. > I also created a "script" element for QF a while back, for just this type of > embedded-scripting scenario, but my changes were rejected. If it's possible, > I'd like to propose that as a QF subpackage, since I think it's useful, > particularly in this scenario. I have no idea if there's something different > I have to do to create/propose a subpackage, so input/suggestions on this > point is welcomed. > I never actually looked at this element... Proposing a subpackage is the same as proposing a package. Just get it set up and propose it. -- Justin Patrin