Re: Re: Help with extending HTML_QuickForm_select

From: Date: Tue, 08 Feb 2005 01:34:23 +0000
Subject: Re: Re: Help with extending HTML_QuickForm_select
References: 1 2 3 4 5  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-36026@lists.php.net to get a copy of this message
On Mon, 07 Feb 2005 17:19:18 -0800, Jamie Alessio <Jamie.Alessio@ucop.edu> 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? Just put <script> entries in the output. i.e. output the normal select (with the parent's toHtml method I think) then add a <script> element which hides the normal element and adds the 2 new multi-selects and buttons / links. The easiest way to do this would be to put a div in there with an id, then put the content in it with the JS. > > >>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 > -- Justin Patrin

« previous php.pear.dev (#36026) next »