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

Modal data-remote URL not called with each click. #6865

Closed
mangelo123 opened this issue Feb 9, 2013 · 4 comments
Closed

Modal data-remote URL not called with each click. #6865

mangelo123 opened this issue Feb 9, 2013 · 4 comments
Labels

Comments

@mangelo123
Copy link

I am using the modal dialog on a Grails based application. The first time I click a link (using the <a> tag) my action is fired as I can see in my debugger and I'm able to operate on data. Any link clicked afterwards is no longer 'loading' the URL specified by data-remote so the same dialog from the first attempt is displayed over and over.

I am assuming that this would work correctly in the javascript version. Is there no way for this to work with the data api version?

@mangelo123
Copy link
Author

I did replace my data api approach with the comparable JQuery javascript (ajax) and it does work on every click. Having the modal dialog work this way with the data api approach would be much cleaner.

@cvrebert
Copy link
Collaborator

cvrebert commented Feb 9, 2013

Technically a duplicate of #4197, which was (IMO, hastily) automatically closed via a pedantic haunt message; a number of users commented on the issue in support of the feature.
Previous pull requests #4224 & #4468 (implementing such a feature) were rejected via automated haunt messages for not precisely adhering to Bootstrap code guidelines.
A variation was previously rejected by an actual human response by @fat in pull request #6793.

(Solely to complete all the cross-referencing: #4803)

@fat
Copy link
Member

fat commented Jun 28, 2013

closing – this is by design.

@tmorehouse
Copy link
Contributor

Having the remote content modal respect the caching specified by the server would be best (i.e. set an expiresheader when the document is served).

@twbs twbs locked and limited conversation to collaborators Jul 14, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants