Re: [SMW-devel] [SF] Programming Form Input

[Sal Q. <sal...@gm...>]

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:kat...@gm...] 
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