Help with jQuery SlickGrid

[Nitesh]

hey szlamany,

I haven't gone back to the slickgrid. I've had to take a whole other route. Glad to hear you are going well though. as Gary said, It would be great if we colud see a demo

[Webskater]

I've read this thread with interest and have completely missed the point. Everything that is being done (as far as I can see) can very easily be done with bog standard .net and a bit of ajax ... the two principal posters are clearly very switched on so I've missed the point.

What are the benefits of this 'slickgrid ... javascripty' approach over standard .net?

[szlamany]

By the way szlamany, is the site you are creating public facing so that we could take a look at the fruits of your labour? Would be interesting to see.

I'm doing three sites at the same time with this app - all NOT public facing (health info for kids visiting a nurse, financial accounting for a small school district and student information at a large school district).

hey szlamany,

I haven't gone back to the slickgrid. I've had to take a whole other route. Glad to hear you are going well though. as Gary said, It would be great if we colud see a demo

Why don't you both PM me a bit of "who you really are" and I'll see if I can reply back with a link for you to follow...

I've read this thread with interest and have completely missed the point. Everything that is being done (as far as I can see) can very easily be done with bog standard .net and a bit of ajax ... the two principal posters are clearly very switched on so I've missed the point.

What are the benefits of this 'slickgrid ... javascripty' approach over standard .net?

For me it was all about "control over what was going on" that made me leave standard-net+bit-of-ajax. I'm doing 100%-the-same-thing that asp.net/ajax does but I'm doing it myself from the ground up.

Look at what I'm doing now and see how this wouldn't really be possible with asp.net/ajax.

I need to have an autocomplete dropdown with 5000 items in it - account numbers to pay financial transactions against. And that dropdown appears in a primary spot on my screen - but also will have to appear in any place you can edit an account number. That might be a slickgrid that pops up because I'm looking at a batch or an "edit panel" for doing detail editing of a record.

I "transmit" the drop down / autocomplete "array" once - when the page boots. I can "clone" that autocomplete UI-widget with jQuery and make it appear anyplace I want during the life-cycle of the page.

Look at the image below - I show the autocomplete as I'm typing "10-" (that's too vague for my settings) and you see my "more specific" message - as I get to "10-01" it's showing a list.

Then the bottom image shows the opening of an empty OPENAP batch and the ADDING of a new record - that same autocomplete dropdown appears in that spot as well.

That "elevating" of a simple input control to a autocomplete is done all CLIENT SIDE with JS with this code

    options = {};
    options.source = $("#acs-acctlookupinput").autocomplete("option", "source");
    $("#" + strNewId + " .awc-Account").autocomplete(options);

This line of code

options.source = $("#acs-acctlookupinput").autocomplete("option", "source");

is where I'm stealing the source from the other CONTROL on the screen. And now that I'm comfortable with the jQuery api syntax this .chain'ing of methods makes so much sense

I'm about to change this code so the "source" comes from a JS FUNCTION that takes the "source" from a GLOBAL page array. I can then future architect that JS FUNCTION to "sense" that the account cache is stale and refresh with an AJAX call back to a web service.

All without a single PAGE POST BACK - all AJAX - never re-load the page.

How would I have done any of this with asp.net/ajax?

I'm sure with a bit of truely heavy pushing you could "update panel" a drop down to appear - and somehow hack into the final events of that drop down appearing and re-direct the source of the dropdownlist to be another controls data - so you could avoid re-transmit of 5000 entries... Or not give your customer this level of rich UI experience - which unfortunately ended up happening too often for my liking
.

[Webskater]

I'm doing three sites at the same time with this app - all NOT public facing (health info for kids visiting a nurse, financial accounting for a small school district and student information at a large school district).Why don't you both PM me a bit of "who you really are" and I'll see if I can reply back with a link for you to follow...For me it was all about "control over what was going on" that made me leave standard-net+bit-of-ajax. I'm doing 100%-the-same-thing that asp.net/ajax does but I'm doing it myself from the ground up.

Look at what I'm doing now and see how this wouldn't really be possible with asp.net/ajax.

I need to have an autocomplete dropdown with 5000 items in it - account numbers to pay financial transactions against. And that dropdown appears in a primary spot on my screen - but also will have to appear in any place you can edit an account number. That might be a slickgrid that pops up because I'm looking at a batch or an "edit panel" for doing detail editing of a record.

I "transmit" the drop down / autocomplete "array" once - when the page boots. I can "clone" that autocomplete UI-widget with jQuery and make it appear anyplace I want during the life-cycle of the page.

Look at the image below - I show the autocomplete as I'm typing "10-" (that's too vague for my settings) and you see my "more specific" message - as I get to "10-01" it's showing a list.

Then the bottom image shows the opening of an empty OPENAP batch and the ADDING of a new record - that same autocomplete dropdown appears in that spot as well.

That "elevating" of a simple input control to a autocomplete is done all CLIENT SIDE with JS with this code

    options = {};
    options.source = $("#acs-acctlookupinput").autocomplete("option", "source");
    $("#" + strNewId + " .awc-Account").autocomplete(options);

This line of code

options.source = $("#acs-acctlookupinput").autocomplete("option", "source");

is where I'm stealing the source from the other CONTROL on the screen. And now that I'm comfortable with the jQuery api syntax this .chain'ing of methods makes so much sense

I'm about to change this code so the "source" comes from a JS FUNCTION that takes the "source" from a GLOBAL page array. I can then future architect that JS FUNCTION to "sense" that the account cache is stale and refresh with an AJAX call back to a web service.

All without a single PAGE POST BACK - all AJAX - never re-load the page.

How would I have done any of this with asp.net/ajax?

I'm sure with a bit of truely heavy pushing you could "update panel" a drop down to appear - and somehow hack into the final events of that drop down appearing and re-direct the source of the dropdownlist to be another controls data - so you could avoid re-transmit of 5000 entries... Or not give your customer this level of rich UI experience - which unfortunately ended up happening too often for my liking
.

Very interesting ... and thanks for that explanation.

It reminds me a bit of something I did in an old asp application once. I was developing for a company with about a 1000 users - all of whom did different jobs (obviously). There was an endless need to create a list of these users or a filtered list depending on what they did and what page you were on and who you wanted to allocate things to etc. I initially started out with lots of calls to the database to get what was basically a variable subset of the same data and I kept thinking how to short circuit it.

In the end I used a frames page and the first time the page loaded I downloaded the entire list of users into a javascript array in the 'head' frame. After that every time I need a list of users (or a list filtered by category etc) it was just one call to a javascript function and my drop down list (or table) was populated client side. Worked like a charm. The head frame auto refreshed every 5 minutes so if someone made a change to a user's details it soon was available throughout the app. Not ideal - but a reasonable compromise as it save literally hundreds of database calls throughout the app.

I too used it for autocomplete - a search box in the head frame called an onkeypress function that filtered the list and displayed it in a div below the text box. Best autocomplete I've ever done - none of the .net calling a web service nonsense (which, to be fair, does work well but is occasionally sticky). Everything client side and so fast.

[szlamany]

hey szlamany,

I'm afarid I've had to abandon this approach. I did everything I needed to like save data oncellchange etc, until I got to the grouping part.

I grouped the data by a field and the grid looked great, until I started clicking on a row and trying to get the row data. The grid was giving me Row 5 data for example if I clicked on Row 1.

And I realised it ain't my mistake cos I even tried it on the slickgrid example and got the same result

I'm afaid I wasted 2 weeks of development and I now have to look for an alternative approach. I did learn quite a bit about JSON though so I guess all is not lost

btw - I've discovered even though the slickgrid is only displaying your "source" array of data - you need to use the slickgrid .getXXX functions to get row and column "data". I've not done grouping in any ways yet but I'm not having problems getting back to my data for UPDATE calls to the DB...