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.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:
>>
>> http://test12.wikivote.ru/index.php?title=D&action=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
>> 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
>> http://wikivote.ru
>>
>>
>
>
> --
> WikiWorks · MediaWiki Consulting · http://wikiworks.com
>
------------------------------------------------------------------------------
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
