Re: [SMW-devel] [SF] Patch to bring back IDs for SFDateInput

[Yaron K. <ya...@gm...>]

Hi,

Okay - that sounds like a perfect case where jQuery can let you use classes
instead of IDs. The key is that the buttons have to be contained within the
same div or span as the date input - if you can get that to happen (or maybe
that's how it works already), then it's pretty easy to get each button to
affect only its corresponding date input, without the use of IDs.

You can see that strategy being used in a few places here:

http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/SemanticForms/libs/SemanticForms.js?view=markup

<http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/SemanticForms/libs/SemanticForms.js?view=markup>For
instance, this section of code is the beginning of the "addInstance"
function, which is attached to every "Add another" button:

jQuery.fn.addInstance = function() {

...
 // Create the new instance
var new_div = this.closest(".multipleTemplateWrapper")
.find(".multipleTemplateStarter")
.clone()
.removeClass('multipleTemplateStarter')
.addClass('multipleTemplateInstance')
.addClass('multipleTemplate') // backwards compatibility
.removeAttr("id")
.css("display", "block");


...and then elsewhere in the code, there's this line:

jQuery('.multipleTemplateAdder').click( function() {
jQuery(this).addInstance(); } );

If I can give a mini-jQuery tutorial: "addInstance" gets defined as a
function for any page element - in this case, it gets used for "Add another"
buttons. When the function is triggered (via a click), the code looks for
the button's parent div with the appropriate class (the closest() function),
then finds, within that div, the sibling element that it needs to act on
(the find() function), then acts on it (all the rest). The key to this is
that every relevant part of the structure needs to have its own class.

It looks a little weird, and it takes a little getting used to this way of
doing things, but it really makes life simpler over the long run - and
there's some good documentation for jQuery online.

I hope you can get it working...

-Yaron


On Tue, Jan 18, 2011 at 11:32 PM, Patrick Nagel <ma...@pa...>wrote:

> Hi Yaron,
>
> On 2011-01-17 13:56 UTC Yaron Koren wrote:
> > Could you explain what your SFDateInput extension does? The general
> > approach when using jQuery, which I've tried to get SF to follow, is to
> > use classes instead of IDs whenever possible - it leads to significantly
> > simpler code. Is it possible that your extension could do the same thing?
>
> It simply adds buttons that let users enter 'today', 'tomorrow', or
> 'yesterday' with one click.
>
> I don't know how I could use classes in that case - the buttons next to a
> date
> input should only enter the date into one specific DateInput, not into all
> DateInputs. I think I need something (IDs?) to uniquely address each field,
> don't I?
>
> Patrick.
>
> --
> Key ID: 0x86E346D4            http://patrick-nagel.net/key.asc
> Fingerprint: 7745 E1BE FA8B FBAD 76AB 2BFC C981 E686 86E3 46D4
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Semediawiki-devel mailing list
> Sem...@li...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>


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