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




On Thu, May 10, 2012 at 6:20 PM, Stephan Gambke <s7ep...@gmail.com> wrote:

> Hi Yury,
>
> very nice input, I love it.
>
> On 10 May 2012 12:26, Yury Katkov <katkov.ju...@gmail.com> 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
> HeaderTabs:
>
> $parser->getOutput()->addHeadItem( HTML::inlineScript(
>
> 'document.styleSheets[0].insertRule?document.styleSheets[0].insertRule(".unselected
> {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.
>
> Cheers,
> Stephan
>
------------------------------------------------------------------------------
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

Reply via email to