Hi Yury,

I just checked in the SF part of your patch - thanks! I'm planning to make a similar change for the other form inputs at some point - it will most just involve a bunch of find-and-replaces.

-Yaron

On Fri, May 11, 2012 at 2:47 PM, Yury Katkov <katkov.juriy@gmail.com> wrote:
Hi Yaron and Stephan!

I have a big breakthrough with my input. It now supports now all the parameters that SFListBoxInput supports and I have removed almost all of my code. Long live Inheritance!
I have to refactor SFListBox class a bit and move all the logic from getHTML() which is now marked as deprecated and not recommended for overriding to getHtmlText().

After that I remove all the wheels I have invented in my class, then I extended SFListBox, added my javascript to it - and wow, it's working very nice, it supports 'values from property', 'values from category' and all the other cool attributes you programmed in SFListBox!

I add the zip-archive to this letter in which you'll find:
* the images
* the patch with refactored SFListBox for Semantic Forms
* the patch with my PHP class and all the needed js and css

The patches are created by TortoiseSVN tool.

I'll be very grad if you apply these patches to first to SF and then to SFI.

Sincerely yours,
-----
Yury Katkov





On Fri, May 11, 2012 at 5:56 PM, Yury Katkov <katkov.juriy@gmail.com> wrote:
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 <yaron@wikiworks.com> wrote:
Hi Yury,

My answers are below.

On Thu, May 10, 2012 at 6:26 AM, Yury Katkov <katkov.juriy@gmail.com> wrote:
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:


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:


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 ofgetDefaultPropTypes,getDefaultPropTypeLists andgetOtherPropTypesHandled.
3) In the futureaddJsInitFunctionData,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:


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

The basic rule is that SF holds the input types that are considered "essential" in some way, while SFI holds everything else (other than the input types defined in Semantic Maps, etc.). Sometimes it's a gray area, although this input clearly (to me) looks like it should go in SFI. As for compatibility - as long as it works with the latest version of everything, I think it's fine. The important thing is that MediaWiki < 1.17 (i.e., pre-ResourceLoader) no longer needs to be supported.

Cheers!
-----
Yury Katkov,
WikiVote! company.
E-government and law crowdsouring



--
WikiWorks MediaWiki Consulting http://wikiworks.com





--
WikiWorks MediaWiki Consulting http://wikiworks.com