Re: Option Transfer in QF

On Fri, 11 Feb 2005 16:30:00 -0800, Jamie Alessio <Jamie.Alessio@ucop.edu> wrote: > Justin Patrin wrote: > > On Fri, 11 Feb 2005 15:35:58 -0800, Ken Restivo <ken@restivo.org> wrote: > > > >>On Fri, Feb 11, 2005 at 02:15:51PM -0800, Justin Patrin wrote: > >> > >>>On Fri, 11 Feb 2005 13:53:15 -0800, Ken Restivo <ken@restivo.org> wrote: > >>> > >>>>Has anyone implemented multiselect option transfer using QF? I'd rather > >>>>not be blazing new ground on which no human has ever tread. > >>>> > >>>>Basically an option-transfer is somewhat similar to a heirselect, and if I had > >>>>to implement it myself I'd probably start by subclassing or copy-pasting the heirselect code. > >>>> > >>>>Here's a non-QF example: > >>>>http://www.quirksmode.org/js/transfer.html > >>>> > >>> > >>><snip> > >>> > >>>Funny you should ask now. There are no currently published > >>>implementations, but Jamie Alessio is working on one (CCed to this > >>>message). It may even be done by now. Check the PEAR-Dev list for the > >>>discussion about it. > >>> > >> > >>Interesting... and pretty slick. Alas, I can't use it. His advmultselect > >>implementation (with your suggestion of a hidden field) now seems to use JS exclusively and > >>won't work at all in non-JS browsers. > >> > >>But there are some good ideas there and that will help me along, thanks. > >> > > > > > > Ah...I didn't read your entire post. Well, there's no easy way to make > > such a thing work without JS. Jamie's version is going to be a normal > > multiselect when there's no JS support. Making this kind of thing work > > without JS would put lots of limitations on the script that uses it. > > It would certainly break QFs in many situations to submit but not > > process normally. > > > > IMHO if someone has turned off JS (or it's not supported) a normal > > multi-select is fine. JS is pretty ubiquitous now and it's needed for > > any kind of dynamic processing. > > > Ken, > I must admit that I didn't see your entire original post either. Somehow > your message never made it over to the gmane.org news server which is > what I read this list from so I was responding only to what Justin had > included. I didn't realize you were proposing to move the values back > and forth with trips to the server and additional PHP+QF processing. > > This approach seems do-able and you probably won't even need to make any > changes to the QF code. Instead, you'll just need your PHP script to > check which button on the form caused the 'submit' and if it was one of > the buttons that is for the option transfer just skip past QF's validate > functions and redraw the form with the data moved between your two > multi-selects. I'm sure that's a grossly over-simplified version but I'm > thinking it won't be too tricky to implement (and in my opinion, > probably way less tricky than accomplishing it with javascript). > Yes, this is workable, but my point was that this isn't really do-able as a reusable element. You can do with *with* QF and a controller script, but implementing it as a reusable element (like yours) is nearly impossible. Especially if, say, the action is not the script which outputs the form. One possibility to all this is to add a callback rule to the form in onQuickFormEvent on the addElement event. The callback rule would check the clicked button and if it's one of this element's "move" buttons would do the required changes to the element (this isn't actually possible as the rule doesn't have access to the form...perhaps when the element gets the "addElement" event it could check the submitted values and move things around...) and return a validation error, which would stop the form from being processed. -- Justin Patrin