Craig Stuntz

Forum Replies Created

Viewing 10 replies - 1 through 10 (of 10 total)
  • Author
    Replies
  • in reply to: grid.history demo is live #95300
    Craig Stuntz
    Participant

    I've now added documentation for the plugin, available via the demo page.

    in reply to: grid.history demo is live #95270
    Craig Stuntz
    Participant

    Apologies to those who tried

    in reply to: How do I contribute a feature? #94415
    Craig Stuntz
    Participant

    Hello? Anyone home?

    -Craig

    in reply to: Extension points / plugin API #94330
    Craig Stuntz
    Participant

    tony said:

    Hello,

    this is maybe what you looking for:

    $.extend($.jgrid.defaults,{…});

    before creating a grid Wink

    Regards

    Tony


    That doesn't fix the problem. If the grid user binds beforeRequest, then my code doesn't run. Existing plugins (e.g., treegrid, subgrid) require modification of grid.base.js. to work. That's bad; the grid should not depend on its plugins. What if I could do:

    $.jgrid.plugins.bind("beforeRequest.jqGrid", function() { myPluginCode(); });

    (or other events). Then a plugin author could write a plugin which works without having to change grid.base.js for every plugin.

    in reply to: Extension points / plugin API #94269
    Craig Stuntz
    Participant

    Tony,

    Thanks for responding, but that doesn't answer my question. I will try to clarify.

    I know that there is a beforeRequest event, but to handle it I need to change options to include a handler for beforeRequest. So a user of my plugin could write:

    $(“#grid”).jqGrid({ beforeRequest: function() { $.gridHistory(this) } });

    …but that's an incredibly awkward way to use a “plugin”, especially if the user is already hooking beforeRequest for something else.

    I would prefer that the user could just write:

    $(“#grid”).jqGrid({ history: true });

    What I'm asking for, essentially, is a global beforeRequest handler (well, better still would be an event which ran once when the grid was created, not before every request — but even a global beforeRequest is better than what I have now). One which always runs for all grids, not one specific grid. Like I said, it would go in the global $.jgrid rather than the grid-specific options object.

    Does that make more sense?

    Thanks,

    -Craig

    in reply to: Using jqGrid with ASP.NET MVC: A Tutorial #86969
    Craig Stuntz
    Participant

    The search argument in the action method comes from the filterModel.name in the call to jqGrid.filterGrid. Did you read the “search and formatting” article and download the solution there? This is explained in that article, along with why the method I use for search might not be right for every application.

    in reply to: Using jqGrid with ASP.NET MVC: A Tutorial #86707
    Craig Stuntz
    Participant
    in reply to: Using jqGrid with ASP.NET MVC: A Tutorial #86603
    Craig Stuntz
    Participant

    I just added a new article to the series:

    Using jqGrid with ASP.NET MVC: Search and Formatting

    This update also fixes a bug in paging in the original sample code.

    in reply to: empty treegrid with client side data #86486
    Craig Stuntz
    Participant

    Would you mind sharing your code? It could really help me out.


    Here, I made you a demo:

    $(document).ready(function() {

    in reply to: empty treegrid with client side data #86456
    Craig Stuntz
    Participant

    This is working correctly for me. I am using a tree grid and populating it with data on the client side. I'm using the adjacency model. Which part is not working for you?

Viewing 10 replies - 1 through 10 (of 10 total)

Stay connected with us in your favorite flavor!