$.fn.watermark conflicts with Microsoft Ajax Control Toolkit Watermark Extender

[GoogleCodeExporter]

In the latest release of the MS Ajax Control Toolkit (40412), there appears to 
be a conflict with the $.fn.watermark function definition.

When $(selector).watermark() is called when the MS Ajax Control Toolkit 
watermark extender is also being used on the page, the function that actually 
gets called is:

function anonymous(WatermarkText, WatermarkCssClass, properties) {
/// <summary>Creates an instance of the type 
'Sys.Extended.UI.TextBoxWatermarkBehavior' and sets the given 
properties.</summary>
/// <param name="WatermarkText" type="String"></param>
/// <param name="WatermarkCssClass" type="String"></param>
/// <param name="properties" type="Object" mayBeNull="true" 
optional="true">Additional properties to set on the component.</param>
/// <returns type="Sys._jComponentSet" />
var args = arguments,    callee = args.callee,    component = 
callee._component,    source = Sys.create;component.defaults = 
component.defaults || callee.defaults;if (component._isBehavior) {    source = 
new Sys.ElementSet(this.get()),    source._jquery = this;}return 
source[component.name].apply(source, args);
}

The method signature is different than the jquery watermark function so the 
class that gets assigned to the input become [object Object].

The code for the anonymous function doesn't appear to be transmitted (when 
looking in Fiddler) so I'm guessing the code is somehow created dynamically on 
the client.

See attached web forms project.

Original issue reported on code.google.com by richard....@gmail.com on 22 Sep 2010 at 5:23

Attachments:

• WatermarkTest.zip

[GoogleCodeExporter]

I  have a couple of thoughts here.  First, i'm not sure why you'd want to use 
two different watermark controls/plugins.  If you're using the MS Ajax Control 
Toolkit, I'd recommend using the built-in control there.

My other comment is that I don't think the MS Ajax Control Toolkit has much 
life left to it, and doesn't appear to have much development going on.

I'm not sure if there is or isn't a conflict with this plugin, but even if 
there were, does it really make sense to change everything around to satisfy 
this conflict?

This is not intended to invalidate your issue, but just to explain my thoughts 
on this and give some feedback.

Original comment by t...@speednet.biz on 6 Oct 2010 at 7:16

[GoogleCodeExporter]

Sorry for the delayed response

There definitely is a naming conflict.  MS Ajax now allows the use of jQuery 
selectors to add "extender behaviors" to elements on the client side.  If I 
rename this plugin to jqwatermark, everything works with it.  In the end, 
that's probably going to be my only option since both sides in an issue like 
this are going to feel they are in the right.

You make it sound as though choosing one or the other is simple, or that having 
to choose one set of controls over another is acceptable.  There is no reason 
they shouldn't be able to co-exist, if properly namespaced as recommended by 
the plugins authoring guide.  What if Microsoft or JQuery wrote their libraries 
so one wouldn't work with the other, how bad would that be?  The thought that a 
user should have to choose one or another is a really bad one.

I am using a composite control that is comprised of MS Ajax Date, Watermark, 
MaskedInput and validators.  It's an MS Ajax control that stands on its own 
without dependencies on another library.   On the same page I am using YUI 
autocomplete.  The MS Ajax Watermark isn't compatible with YUI autocomplete 
because it overwrites the element class rather than being additive (Yes, this 
plugin is a more sane implementation).

The MS Ajax Control Toolkit was released along with VS2010.  Just because they 
aren't doing monthly updates doesn't mean it, or server side control 
development is dead.  I've done a bunch of wrapping JS controls into .NET 
controls.  Though there is some effort in doing that, once complete, usage of 
the controls is actually much simpler than through JavaScript alone.  But if I 
can composite existing server side controls, that's much easier than having to 
wrap up JS controls.  So yes, I mix and match the two in an application to get 
the best usability for the user while optimizing my development effort.

The problem lies in both libraries really. There shouldn't be a naming conflict 
like this.  At least with YUI, everything is accessed through namespaces.

Original comment by richard....@gmail.com on 20 Oct 2010 at 2:53

[GoogleCodeExporter]

If it's a naming conflict, you can either rename the plugin (as you suggested), 
or else just be sure that my plugin loads AFTER the MS Ajax plugin, so that it 
will undo the watermark plugin installed by Microsoft.

Original comment by t...@speednet.biz on 22 Oct 2010 at 3:50

[GoogleCodeExporter]

There is always the option of using the no conflict method included w/ the 
jquery library. IOW:

<script language="javascript" type="text/javascript">
    $j = jQuery.noConflict();
</script>

So now, instead of using something like $("#txtboxId").watermark(); you'd use 
$j("#txtboxId").watermark();.  Of course, all of your jquery prefixes on that 
page will need to use the "$j" prefix instead of the standard "$" prefix.  
However, we use MS Ajaxtoolkit's watermark side by side with this jQuery 
watermark without problems since making that change.  

Since the portal we manage has historically used the MS Ajax watermark across 
hundreds of controls, using the "noConflict" method of the jQuery library was a 
nice compromise to be able to use conflicting add on's like this one without 
having to go through an enormous code base overhaul to toss the MS Ajax 
watermark that has served us well up till now.

Original comment by mars...@gmail.com on 24 Nov 2010 at 5:50

[GoogleCodeExporter]

As suggested by marsh76, this can be solved with the noConflict() function.

Original comment by t...@speednet.biz on 3 Dec 2010 at 2:45

• Changed state: WontFix