Re: Re: [PEPr] Proposal finished HTML::HTML_QuickForm_advmultiselect

On 6/21/05, Laurent Laville <pear@laurent-laville.org> wrote: > PEPr wrote: > > PEPr has automatically finished the proposal on HTML::HTML_QuickForm_advmultiselect. > > > > Sum of Votes: 9 (0 conditional) > > Result: This proposal was accepted > > > > Further details on the status of the proposal and the votes can be found here: > > http://pear.php.net/pepr/pepr-proposal-show.php?id=255 > > > > If you are the person who initiated the proposal, > > please read the 'Proposal Finished' instructions at > > ð > > E«÷aRlÿdJAhttp://pear.php.net/manual/en/newmaint.proposal.step3.php#newmaint.proposal.step3.stage4 > > > > hi all, > > First thanks to all who have voted yes for this proposal. > > Second, i'm a bit sorry to have been so late to put this online, but > as i said i've found a better implementation that will allows to use > both browsers with and without javascript (enabled or not). > > Resume of changes: > - double click is no more allowed due to replacement > (multi-select by div+checkboxes) :-( I liked that particular feature. Then again, I implemented it. ;-) > - include part of PHP_Compat code (see PHP_EOL constant usage) IMHO PHP_EOL *really* isn't needed here. First, either one should work fine in either environment. Second, it introduces extra unneeded concatenation (you can just do: $var = 'code more code'; Third, the code that is output doesn't *need* newlines after all, HTML and JS work fine with or without newlines. I suggest you just use single strings like getElementJs does. > - no more use multiple select boxes (unselected, selected, and hidden) > but instead use checkboxes to solve easily the CTRL+click Good and bad. I'll discuss more below. > - overloaded select load API to allows fancy attributes (see example 7) 1) please don't use @ (@$param2[$key]) Better would be to do this at the top: if (!is_array($param2)) { $param2 = array(); } Then use isset($param2[$key]) 2) Why are you setting the params in the parent::load call? Shouldn't that just be parent::load($options, $param1, $param2, $param3, $param4); 3) IMHO this function is really not needed. I agree with the previous posters about this. If you want to include attributes for your options, write a simple loop yourself and add options each with attributes. Putting your attributes in a big array and sending it in is bound to have some kind of logic to put them in that array. Replace that loop with a loop around addOption and you're none the worse for wear. > - new API getElementCss() to get stylesheet required (auto insert > in html rendering phase: see toHtml() API) > - getElementJs() is new API (changed to public) that replaced > old _getJs() > - easy integration into template environnement with getElementCss() and > getElementJs() and setElementTemplate() > Remove or keep placehoders {stylesheet}, {javascript} I like these changes. > - MAJOR and IMPORTANT change is to unselect data operation: > if you want to remove an item, just uncheck it, and keep others checked > Ok, time to discuss the div/checkbox thing. I like the look of this very much. However, I don't think it's appropriate here. The whole point of creating this dual-select system was to overcome users' fear / ignorance of CTRL-click. I see this div/checkbox thing as another solution entirely. To put it another way, having two multiselects next to each other with >> and << buttons is one solution to this problem. Having the multiselect replaced by a series of checkboxes is another, entirely different, solution to the problem. Putting both in one solution is IMHO very confusing. Also, making the "selected" box have the checkboxes selected is also confusing. Users won't know how the system works. I propose that these two solutions be split up and either put into their own elements ot be an option in this element. You should be using one or the other, not both. I guarantee that this is going to confuse users rather than empower them. To reiterate, I like both solutions but I think they should be seperate solutions. You should be using one or the other, not both at once. Both are useful in different situations. -- Justin Patrin