Hi Yury,
I just tried your test link in Firefox under Windows 7 and I see different behavior than I saw under IE 9.0. Now I understand the confusion I gave you. Under IE 9.0, this is what I see before it shows your form as a multi-list box with no boxes on the right: Have you seen it working as expected with IE? Sal From: Yury Katkov [mailto:katkov.ju...@gmail.com] Sent: Thursday, May 10, 2012 11:18 AM To: salqu...@gmail.com Cc: SMW developer list Subject: Re: [SMW-devel] [SF] Programming Form Input Hi Sal! As far as I can tell the first problem that was related to the Ctrl key has been solved in my input, hasn't it? The selected elements move from the left box to the right box and remains in a right box till the end of eternity. > The other problem when you have a large list that doesn't practically fit on the screen is verifying that a user wanted to select was selected. A read-only box on the side that shows what has been selected would be a great way to let users track their work. Could you illustrate this situation (probably with a picture)? I'm not sure that I understood the problem and your proposed solution. As of now I plan to add search support to my input. In fact it's already done in the library I use so it's probably won't be difficult. Searching can help address the problem with many items in a list. ----- Yury Katkov On Thu, May 10, 2012 at 10:09 PM, Sal Quintanilla <salqu...@gmail.com> wrote: Great job Yury, multi-select list boxes are a good addition. And to prove you've created a viable option, I'm going to give you some improvement suggestions. What you have works like a traditional multi-select box. But the classic problem with that is an accidental click inside the box, or a click where you didn't quite hold the ctrl key well enough, causes the user to lose his selections. It would be great see an implementation that used a toggle click. that is, click to select a name, and it stays selected until the user clicks to unselect it. The other problem when you have a large list that doesn't practically fit on the screen is verifying that a user wanted to select was selected. A read-only box on the side that shows what has been selected would be a great way to let users track their work. Take care. Sal From: Yury Katkov [mailto:katkov.ju...@gmail.com] Sent: Thursday, May 10, 2012 3:27 AM To: SMW developer list Subject: [SMW-devel] [SF] Programming Form Input Hi everyone and especially SF/SFI developers! I've just finished the pre-alpha version of the new Semantic Form Input for selecting multiple items in a comfortable way. You can see the demo here: http://test12.wikivote.ru/index.php?title=D <http://test12.wikivote.ru/index.php?title=D&action=formedit> &action=formedit I want to write a piece of technical documentation for myself and for future generations of SFInput writers but I don't yet understand several imporant things about Form Inputs. I'd be very glad if Semantic Forms developers clarified something for me. == Question 1. History and future plans == As far as I can tell from the code there are three generations of FormInputs exist now, am I right? 1) in the past input developer had to override getHTML() function. It's done in most Semantic Forms's formsinput but it's not a good way anymore. We also have used 2) now it's the era of the Resource Loader and to create my input I have to override getHtmlText, getResourceModuleNames and getJsInitFunctionData functions. For figuring out what kind of data can be handled by the input we now use getHandledPropertyTypes function instead of getDefaultPropTypes, getDefaultPropTypeLists and getOtherPropTypesHandled. 3) In the future addJsInitFunctionData, addJsValidationFunctionData will be used by the internals of the Semantic Forms and all deprecated methods will be removed. == Question 2. Naming == Is it correct that I have to name my inputs like that: "input_" . $this->mInputNumber == Question 3 Naming again == What the 'name' attribute is used for? The rule of the thumb is of course that you always make it like that: $this->mInputName == Question 4. Handling lists == I'm not sure that I understand about handling lists issues in Form Inputs. 1) The Name attribute of the form input sometimes have brackets like in it like this: input3[]. 2) On the other hand sometimes we add an additional hidden element like Html::hidden($name . '[is_list]', 1) 3) And thirdly we have the method canHandleLists() to override. It seems that all three thing are indicating that the form input can handle lists, but it's pretty weird to see three different pieces of code trying to say the same thing. What's happening == Question 5. Don't draw my input without proper CSS! == When the form is loaded there's a period of time when the user can my element undressed. Namely the user can see he input without any CSS applied to it. How can I avoid such an effect? == Question 6. Be part of something bigger == Is it possible that my code will be part of Semantic Forms Inputs or Semantic Forms? If so, what versions of SMW, SF, SFI should I use for testing? What versions I have to be compatible with? Cheers! ----- Yury Katkov, WikiVote! company. E-government and law crowdsouring http://wikivote.ru
<<image001.png>>
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
