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:D. as Gary said, It would be great if we colud see a demo;)
Printable View
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:D. as Gary said, It would be great if we colud see a demo;)
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?
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).Quote:
Originally Posted by gep13
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...Quote:
Originally Posted by Nitesh
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.Quote:
Originally Posted by Webskater
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
This line of codeCode:options = {};
options.source = $("#acs-acctlookupinput").autocomplete("option", "source");
$("#" + strNewId + " .awc-Account").autocomplete(options);
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.Quote:
Originally Posted by szlamany
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.
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...Quote:
Originally Posted by Nitesh