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

2012-05-11 Thread Yury Katkov
Hi Yaron!
I found the answer to my question about the square brackets in form input's
name. It's done for PHP to know that all the values of the same name must
be collected in an array.

Here is it : http://docs.php.net/manual/en/faq.html.php#faq.html.arrays
-
Yury Katkov




On Thu, May 10, 2012 at 5:27 PM, Yaron Koren ya...@wikiworks.com wrote:

 Hi Yury,

 My answers are below.

 On Thu, May 10, 2012 at 6:26 AM, Yury Katkov katkov.ju...@gmail.comwrote:

 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=Daction=formedit


 Nice. Does this input type use an existing JS library, and if so, which
 one? Or did you create the Javascript for it yourself?

 Tied in with that, the name you chose for this input type, multiselect,
 is actually one I was thinking of using for this other input type I wanted
 to add to SFI  - see the Multiple Select section:

 http://harvesthq.github.com/chosen/

 What about calling your input type two listboxes or something like that?
 That seems to be at least one standard term for this kind of interface. I
 don't know if there's a more official one.



 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.


 That sounds right... Stephan Gambke might know more about this than I do.
 I believe the framework for the third of those is not done yet.



 == Question 2. Naming ==
 Is it correct that I have to name my inputs like that: input_ .
 $this-mInputNumber


 The input name is already passed in by SF, no? At the most, you might just
 have to add in a [...], depending on how the HTML is structured, because
 your input holds multiple values This ties in to your 4th question.



 == 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


 It's used when the form is submitted, to get the value of the input.



 == 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


 The second one is done for certain input types, so that when the form is
 submitted, the code will know to check for multiple values. It's a symptom
 of the way arrays of values are handled in HTML forms, but beyond that I
 don't remember. :) If you don't need it, then you shouldn't use it. I think
 that's true for the first one as well.



 == 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?


 That's a symptom of the use of ResourceLoader, since by default it puts
 CSS and Javascript at the bottom of the page. It leads to faster leading
 times, but some people don't like it because things show up undressed.
 (The ResourceLoader people apparently refer to this as a FOUC, or flash
 of unstyled content.) Personally, I don't mind it. But here are
 instructions on how to avoid it for your module:


 http://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension_developers#Adding_a_module_to_the_page



 == 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
 

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

2012-05-11 Thread Yury Katkov
Hi Sal!

It's really a major bug - I'll try to fix that now.
-
Yury Katkov




On Thu, May 10, 2012 at 10:27 PM, trueskew trues...@gmail.com wrote:

 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=Daction=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