Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request: custom request headers #62

Open
phroggyy opened this issue Jun 10, 2015 · 12 comments
Open

Request: custom request headers #62

phroggyy opened this issue Jun 10, 2015 · 12 comments

Comments

@phroggyy
Copy link

I am currently integrating this with a Laravel application, where CSRF protection is enabled by default. I would love to see request headers integrated into gm, for example through an option gm.requestHeaders = {}, where the default is the aforementioned empty object, which can then be overridden with key-value pairs.

@neokoenig
Copy link
Owner

Can you give me an example where this is needed? Is it the save function?

@phroggyy
Copy link
Author

Yep, save function. I fixed it locally for myself, I can either fork you and make a PR, or if you have time to add it yourself, that'd be great.

What I did:

  1. Add requestHeaders: {} to defaultOptions
  2. In the $.ajax of the save function, add headers: gm.options.requestHeaders

@phroggyy
Copy link
Author

It would also be cool if you'd add in a saveData attribute to the options, so that users could extend gm with their own request data (such as a page name, or some type of date, really anything)

@neokoenig
Copy link
Owner

Yeah, I'm actually rewriting the whole thing from scratch at the moment. In the new version, you can either use the built in controls like it currently is, or disable them and easily build your own - i.e, there's lots of event driven stuff like .get() to get the contents of the grid, .destroy(), .reset() etc. So hopefully with that version it should be much more flexible for those wanting to do something other than the reason I wrote it!

@phroggyy
Copy link
Author

Oh sweet!

@neokoenig
Copy link
Owner

Yeah, may be a little while yet though.. I'll flag this ticket as a feature request to make sure I get some of this functionality in the new version.

@phroggyy
Copy link
Author

Is there a branch on which you're developing the next version/another repo where I could contribute?

@neokoenig
Copy link
Owner

Not at the moment, I've only just got the core functions working, and I'm still very much deciding on the best way of doing stuff. TBH I'm not really a javascript developer, so I'm sure I'm doing a bunch of stuff in a more complex way than it needs to be :)

I'll see if I can get something up on a branch in the next week or so.

@phroggyy
Copy link
Author

Grand. I'm no major JS developer either, work mainly in backend, but I work pretty closely with a front-end dev here, and sometimes I end up helping her with things, so I guess I'm at least decent :)

@neokoenig
Copy link
Owner

Highly experimental beginnings of a rewrite:
https://github.com/neokoenig/jQuery-gridmanager/tree/0.4

Check /src/new.html

instance 2 is pretty much the defaults;
instance 1 is me playing with trying to get more external control in.

you can now do things like gm.do("destroy") to kill an instance, add rows etc.etc. or gm.do("get") returns the cleaned contents etc.

Very early stages - just trying to build up a list of the various functionalities which people might want!

@phroggyy
Copy link
Author

Gonna have a look later tonight! I'll probably fork you and do some PRs; I've implemented a couple features for my own project which I could just pull in and add to the branch :)

Also, I'm thinking about a feature which could be very useful, although I'm not yet sure of how it'd work: custom overrides; some streamlined way to implement custom functions and overrides for gridmanager globally, without editing the gm source. One thought is some kind of config file, which has a default path. Since most users will follow default, any instance of gm would use the custom config.

One idea I have is completely overriding functions, so that a user could specify their own save or whatever. Of course, this could probably be done already, but it feels a bit messy, so I'd love if we could together work on streamlining the process

@neokoenig
Copy link
Owner

Cool - have a look at the gm.do() wrapper function - this is one idea of being able to autowrap events - i.e, beforesave or aftersave without having to manually specify the function call from within every function. Not sure if this is the best design pattern for it yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants