I have an application with an accordion. The accordion's section .content is pulled from a server, generated dynamically and can be rather large. Therefore it would be best to load the content only when the user opens the section. My though is that the best way to do this would be binding to a section open event, display a loading icon while fetching the content, then displaying that content.
However, I'm having great difficulty binding to the open event. There does not seem to be a great deal of documentation on the new Foundation 4 section/tabs/accordion. What I did see may have been for foundation 3. It said open/opened/close/closed events should be sent, but they do not seem to be thrown.
The only event I seem able to bind to is "click." Which would work, except the accordion frequently loads with the first section already open. I could run myExampleDynamicLoader($('section.active')) on document ready, but it seems like there should be a less hackish way.
I created a jsFiddle to show what I'm talking about http://jsfiddle.net/HurricaneJamesEsq/6sGGD/14/
Any suggestions?
After reading through the foundation.section.js source, it is pretty clear that sections do not trigger any events. A pull request was added, but in the mean time it looks like this can only be done via 'click' events.
Related
hi i wanna have a filter pre every web pages that check someting and if that thing was incorrect show me an error page
and if it was fine just show me the page
Vaadin is mostly based on individual interactions such as clicking buttons or scrolling in a grid, rather than viewing pages. What you can still do is to use UI::addBeforeEnterListener to get an event before navigating to a new target. You can use a VaadinServiceInitListener to register that listener for all your UI instances.
For more information, have a look at this blog post that I've written on the topic.
There is a 5 second or so after the page is loaded, that e.g. clicking or hovering on elements won't work.
I figured out, it has to do with the Tag Manager.
Just like suggested in the guide, it's loading asynchronously.
Does somebody have any suggestion how to avoid this lag?
GTM shouldn't cause such delays - it loads asynchronously. If you want to test it - remove GTM from the website and check page load time. You can also use WebPageTest and block GTM in the settings to prevent the script from running. Unless there are any custom HTML injections that prevent the buttons from working before all the content is loaded, it isn't GTM.
Looking at the load waterfall you should see which element blocks the page from loading.
I found out what the problem was that was issue in our implementation, not in GTM.
My understanding is that the AjaxFileUpload object uses an iframe to upload files. A postback occurs, but no other controls are posting back - at least that is what it looks like to me as I cannot access any other controls' data.
The purpose of the app is to allow the user to upload a file. It will then modify the contents of that file and save the results to the server. The problem is that it needs some extra information to make the modifications, and therefor needs the information that the user entered elsewhere on the page.
The only solution I have been able to come up with is to do a postback every time one of those other controls is modified, which affects the apps responsiveness. I have been looking for a couple of days for another solution.
Does anyone have any ideas? The best case solution would allow me to access all of the data I need when the AjaxFileUpload control does a postback.
you could have a ajax function that is reading changes from time to time external data, and update the information displayed, similar to email alerts, sorry for my English.
I am trying solve the back button issue within my app. The scenario is:
I have a home page with a search form which sends and receives data with $.ajax(), then the results loaded through ajax, their links points to a controller that won't be done by GET in ajax so that means that the page will be refreshed (so the home page with the results looks like this: http://url/en/home and a result link may look like this http://url/fetch/data/x123av).
The problem is which is the best way fix that when click back button to return the results from the search box?
I have found some answers in stackoverflow related to my question:
http://code.google.com/p/reallysimplehistory
http://tkyk.github.com/jquery-history-plugin
But from the documentation of those plugins, they all work by checking the hash change which I don't have.
Hope I have explained well enough, and I do have searched stackoverflow and google for a solution but I didn't find one that is close to this or either I've jumped over it...
Please just point me to the right way :D
But from the documentation of those plugins, they all work by checking
the hash change which I don't have.
If you want to handle the back button with AJAX request you will have to redesign your application so that it works with hashes as that's the only way. Changing the fragment portion of an url doesn't trigger a page reload but it is added to the history, so when you press the back button you are able to detect this change without navigating away from the page.
As mentioned by SLaks in the comments section another possibility is to use the HTML5 history API but obviously this assumes that the client browser supports it.
If you go to http://jsbin.com/ibozun/2, hit "Add Item," and then hit "Save," you will see that a second dialog is opened on top of the first one. The form in the dialog is posting to itself (no action defined) - this is by design. Because the dialog has duplicated itself, now you have to hit "Cancel" 2 times to get it to close.
The use-case for this setup is a MS MVC3 page with unobtrusive JQuery validation on it. The default scripts (in other words, I have no custom validators - the scripts are straight from MS) cause an ajax call to the server, and JQM treats that the same as a self-posting form - so you wind up with a duplicate dialog if validation fails.
A similar thing happens if the second page as a page, rather than a dialog - the form posting to itself results in a second history entry in the browser, so to get back to page 1, you have to hit back 2 times.
I believed this be a bug in JQM, but after submitting a bug on GitHub, I was told that this is the expected behavior. So, assuming this behavior that will not be changing in the framework, how do I prevent this from happening for my instance (preferring NOT to edit the framework JS)? Do I have to write my own ajax calls for validation so that I can prevent JQM from knowing that anything has happened? That seems unfortunate...
One idea I had was to detect that the nextPage and current page are the same on "pageHide", and manipulate the dialog/history myself, but have had no luck.
Thanks in advance!
First, there is no dialog duplication in the example. Second, my response and an explanation as to why solving the history issues with posting back to the same page for users of the library is hard can be found here. This example is particularly thorny because it's also in a dialog which we don't support linking to, so disabling ajax for the form (ie forcing it to reload), which would work if it were embedded in a page, won't serve.
The quick solution here is to switch the dialog to a page and add the data-ajax=false data attribute to the form. Mind you this causes a page flash/reload and requires that the form document be fully formed with a head including javascript,css, etc.