Thanks Stephan, now I understand about the methods in SFInput! 
Yury Katkov

On Thu, May 10, 2012 at 6:20 PM, Stephan Gambke <> wrote:
Hi Yury,

very nice input, I love it.

On 10 May 2012 12:26, Yury Katkov <> wrote:
> == 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.

You are right, 1) should not be used anymore.
2) and 3) are actually both part of the new mechanism. The comment
about methods not being used yet are actually wrong, I really should
remove them. Generally you should not overwrite the get-methods.
Instead, to register resource loader modules and JS functions you just
use the add methods. The idea behind providing these add-methods is to
make it easier to build up the required datastructure so you do not
have to care about it. Long story short: Leave the getters alone, call
the adders.

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

We have to carefully distinguish between input id and input name here.

When the constructor of SFFormInput is called, you get as parameters
an input number and an input name.
For a simple HTML input element the number of the input should end up
in the 'id' attribute in the format 'input_<number>'.
The name of the input should end up in the 'name' attribute of your
HTML input element. This name is also what is sent back to the server
and finally used by SF to build the page text.

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

Maybe in addition to what Yaron said: If you are really intent to hide
the input until it looks nice you could try the approach from

$parser->getOutput()->addHeadItem( HTML::inlineScript(
{display:none;}", 0):document.styleSheets[0].addRule(".unselected",
"display:none");' ), true );

This is approaching blunt force, though, so you should think carefully
if you really want to do that.

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

I would love to have this input in SFI!
Generally I try for compatibility with MW 1.17 and SMW 1.5.6, maybe,
although having not much contact with SMW from inputs I usually do not
test excessively against that requirement. As for SF, I try to keep
SFI in sync with the current version.