Your fluent APi in html helper is very cool.
Why don't you provide the same approach in javascript side?
For example, I'd like to use the Option API like this:
$("#comboCurrency").igCombo().option().isEnable(false);
But, I need to use Option API like this:
$("#comboCurrency").igCombo("option", "disabled", false);
Hi,
Our countrols are based on jQuery and you can use Fluent API.
If you have igCombo control, you can change option in this way:
// Set
var combo = $("#combo").data("igCombo").option("autoComplete", true) ;
// Get
var combo = $("#combo").data("igCombo").option("autoComplete")
You can find more infromation for how widgets are build here.
Regards,
Stanimir Todorov
Thanks Stanimir, but you're still passing strings instead of just accessing methods and properties the way javascript intended.
You list this:
$("#combo").data("igCombo").option("autoComplete", true) ; //smells, I have to look up the exact spelling and casing of options and methods to use them
Sparkli's syntax is much better :
$("#comboCurrency").igCombo().option().isEnable(false); //works with intellisense & refactoring, hurray!
hi guys,
Our jQuery Widgets are based on jQuery UI, which uses those conventions for setting options.
we can, of course, always implement a chained approach to setting options which follows the fluent pattern, if there is significant demand for it, but this would deviate from jQuery UI - i am not saying it's a bad thing to do, on the contrary.
Thanks
Angel
I hear you Angel, understood it's the jQuery widget convention you're following.
For simple sites, this is fine, but if these controls are intended to be used in complex web apps with heavy clients, using jQuery widgets in their conventional form is not practical IMO.
We recently stopped using all IG controls except the grid because, among other reasons, we couldn't use them like normal javascript objects, which was causing a lot of confusion and slowing our development time to a crawl.