I have a modal dialog in my template. This dialog needs to be triggered from the code programatically. So I need to show the modal through javascript, as I cannot have a data-toggle button to launch the modal-dialog.
The modal was working with bootstrap but with bootstrap-3 its not showing up, even though I can show it from the console directly. the problem here is how can I execute javascript post the template render, to launch the modal-dialog.
There is a Template.rendered/created function which is called, and inside this this.autorun(runFunc) is supposed to run the code to update the DOM element. This is called correctly, but I still cannot trigger the modal to show-up.
Template.createDialog.created = function() {
console.log("teamplate created");
this.autorun(function(){
$('#myModal').modal('show');
});
};
Update:
This works:
Template.createDialog.rendered = function() {
console.log("teamplate created");
this.autorun(function(){
$('#myModal').modal('show');
});
};
Using the rendered function, I am able to trigger the modal to show up. But the problem is that rendered and created both are only called once. And I need a way to trigger the modal dialog consistently if a condition is reached.
This bootstrap modal dialog with meteor is turning out to be painful and hacky. Is it not possible to show/hide modal using some class parameters?
Modals can be tricky to get right in Meteor for exactly the reasons you've discovered. I don't use Bootstrap, but the basic principle is that you need to trigger the modal programatically so that you can run the relevant framework code once you know the html has been rendered but still retain reactivity (this is certainly the case with Foundation and Semantic-UI modals) .
In your use case (which appears to be a single modal), this shouldn't be too much of a problem. Set a reactive variable modalVisible (a Session variable or similar), and use that to show or hide the modal as required.
this.autorun(function(c) {
if (Session.get('modalVisible')) {
$('#myModal').modal('show');
} else {
$('#myModal').modal('hide');
}
});
If you put all of that in the rendered callback then it will only try to show the modal once it's been added to the DOM (without which you'll get an error and the computation will stop running, breaking reactivity). Note that you shouldn't make rendering of the template dependent on a reactive variable - it should always be rendered but only visible based on the value of the modalVisible Session variable.
Apologies if this is too simple for your use case - if so I would recommend investigating the several packages on Atmosphere for Bootstrap modals as others will almost certainly have faced the same problem.
Related
I am following this example https://kadira.io/academy/meteor-routing-guide/content/rendering-blaze-templates
When I click on my links the whole page is being reloaded. Is there any way to load only the template part that is needed and not the whole page?
Edit: Also I noted another problem. Everything that is outside {{> Template.dynamic}} is being rendered twice.
Here is my project sample. https://github.com/hayk94/UbMvp/tree/routing
EDIT: Putting the contents in the mainLayout template and starting the rendering from there fixed the double render problems. However the reload problems happen because of this code
Template.mainLayout.events({
"click *": function(event, template){
event.stopPropagation();
console.log('body all click log');
// console.log(c0nnIp);
var clickedOne = $(event.target).html().toString();
console.log('This click ' + clickedOne);
//getting the connID
var clientIp = null // headers.getClientIP(); // no need for this anymore
var clientConnId = Meteor.connection._lastSessionId;
console.log(clientIp);
console.log(clientConnId);
Meteor.call("updateDB", {clientIp,clientConnId,clickedOne}, function(error, result){
if(error){
console.log("error", error);
}
if(result){
}
});
}, // click *
});//events
Without this event attached to the template the routing works without any reloads, however as soon as I attach it the problem persists.
Do you have any ideas why this code causes such problems?
EDIT 2 following question Rev 3:
event.stopPropagation() on "click *" event probably prevents the router from intercepting the click on link.
Then your browser performs the default behaviour, i.e. navigates to that link, reloading the whole page.
EDIT following question Rev 2:
Not sure you can directly use your body as BlazeLayout target layout.
Notice in the first code sample of BlazeLayout Usage that they use an actual template as layout (<template name="layout1">), targeted in JS as BlazeLayout.render('layout1', {});.
In the tutorial you mention, they similarly use <template name="mainLayout">.
That layout template is then appended to your page's body and filled accordingly. You can also change the placeholder for that layout with BlazeLayout.setRoot() by the way.
But strange things may happen if you try to directly target the body? In particular, that may explain why you have content rendered twice.
Original answer:
If your page is actually reloaded, then your router might not be configured properly, as your link is not being intercepted and your browser makes you actually navigate to that page. In that case, we would need to see your actual code if you need further help.
In case your page does not actually reload, but only your whole content is changed (whereas you wanted to change just a part of it), then you should make sure you properly point your dynamic templates.
You can refer to kadira:blaze-layout package doc to see how you set up different dynamic template targets in your layout, and how you can change each of them separately (or several of them simultaneously).
You should have something similar in case you use kadira:react-layout package.
I'm trying to use the Buttonset widget in JQuery UI. I've got the package loaded and my template renders the radio buttons fine. I have a "rendered" function to call the JQ UI routine to setup the buttonset:
Template.teamList.rendered = function () {
$("#buttonsetID").buttonset();
}
But it looks like the rendered function is being called before the template is rendered! I stick a console.log in the function and it prints out to the console before there's anything on the screen. So none of the radio buttons are set up, therefore the .buttonset() call does nothing. If I make that call in the console after the page is rendered, JQuery UI does the right thing and my button set appears.
Isn't the .rendered function supposed to be called after everything's set up? Am I doing something wrong?
Thanks!
edit:
As an example, the same thing is seen in the leaderboard example.
If you add:
Template.leaderboard.rendered = function() {
alert($('.player').length);
}
When the page is displayed, it will show 0. This makes it difficult to access the DOM items if you need to add some JQuery events or, in this case, a JQuery UI element.
rendered only works for elements which will appear in the DOM the very first time the template is added to the page. Assume that subscription data takes infinitely long to arrive, then look at the template and see which elements would appear in the default state.
Using the leaderboard example, we can't assume that players are available when the leaderboard template renders (it depends on a subscription). To target a player, you should use the rendered callback on the player template.
It's hard to generalize a strategy for when to apply jQuery plugins, but here are some ideas:
Use the rendered callback if the element will always be added in the default state (e.g. the element is hard-coded and doesn't depend on a conditional).
Use the rendered callback of the most specific child template to target that child (e.g. the player template from above).
Consider using an event handler callback to target the element if it's appearance depends on an event (e.g. a button click).
Consider using a template autorun callback to target the element if it's appearance depends on reactive state. See this question for an example.
The jQuery UI dialog drives me up the walls. To the best of my understanding, here's how it works:
When you do $('#myDialog').dialog({...}), it copies the #myDialog element and moves it inside this bizarre widget thing at the bottom of your body tag. This is crazy! It will duplicate possibly unique DOM elements (with ids) when it does this.
So what I'm trying to do is make it behave in a predictable way when I refresh the HTML of the original element (#myDialog). If I do this dynamically, sometimes the dialog doesn't open any more:
http://jsfiddle.net/t67y7/3/
Or sometimes the dialog opens with the old HTML (because it's cached at the bottom of the page that way). What is up with this?
Since nobody seems to have any idea how to tame this beastly dialog, here's the best thing I've come up with to date. I'll accept any superior alternatives.
var original = $('#dialogId')[0];
var clone = $(original).clone().attr('id', 'dialogIdClone');
var saveHtml = $(original).html();
$(original).html('');
$(clone).dialog({
... // other options
open: function (){
// add any dynamic behavior you need to the dialog here
},
close: function(){
$(clone).remove();
$(original).html(saveHtml);
}
});
The purpose of this whole craziness is to keep the HTML of the original dialog unique on the page. I'm not really sure why this can't be the built-in behavior of the dialog... Actually, I don't understand why jQuery UI needs to clone the HTML to begin with.
I know this has been posted for a while, but a less extensive way to handle this issue would be:
$('#your-dialog').dialog({
... // other options
open: function (){
// add any dynamic behavior you need to the dialog here
},
close: function(){
}
});
$('#your-dialog').remove();
This is due to dialog widget wants to be able to control the display and will wrap the inner content of the original dialog then create a brand new one at the bottom of the body.
The draw back of this solution is that the dialogs have to be the first to be initialized to ensure all your 3rd party library widget will operate properly.
Why don't you just call $("#dialogId").dialog("destroy") on close function, like this:
$("#dialogId").dialog({
close: function() {
$(this).dialog("destroy");
// you may want empty content after close if you use AJAX request to get content for dialog
$(this).html('');
}
}
The destroy function will remove the decorated code, and your dialog element will not be duplicate next time you show the dialog.
I added a sample code to jsfiddle.net example.
You need to empty the dialog before opening it.
$("#dialogId").html('');
$("#dialogId").dialog({
close: function() {
$(this).dialog("destroy");
}
}
I've got an asp.net page containing a Textbox with an Autocomplete extender on it.
It's setup so the user can type a short reference code into the textbox and then choose from the list of matching codes returned by the autocomplete.
On the "select", I then call the server using JQuery. I'm currently using $.get here....
The callback function from $.get checks for "success" and then displays a simple-modal dialog containing info about the item they've just selected.
if (sStatus == "success") {
$.modal(sText, {
overlayClose: true,
appendTo:'form',
onShow: function(dialog) {
$("#ccTargets_tabContainer").tabs();
},
onClose: function(dialog) {
$("#<%=TextBox1.ClientID%>").val("");
$.modal.close();
}
});
$.ready();
}
One of the bits of info being loaded here is a JQuery TABS setup, so the onShow function of the simplemodal is used to initiate the tabs which are within the simplemodal.
Now to the crux of my problem.
If I do multiple consecutive "autocompletes" on the same page it all works fine Unless I have selected a different tab on the tabs in the simplemodal ....If I select a different tab, close the simplemodal and then do another autocomplete I get a JQuery error which seems to relate to a selector doing something with the "old" selected tab that was on the "closed" modal.
I'm clearly missing some sort of cleardown / initialisation somewhere, but can't find what it is. Help?
I've tried "tabs.destroy" before the modal call in the code above and I've tried a $.ready() call as indicated too....
UPDATE: Is it something to do with JQuery Tabs appending my addressbar URL with the selected tab's ID?
I've found the problem.
It's with the "history" script that the tabs plugin normally uses. Obviously as I am continually creating and destroying popups there is no history to speak of - it's all done outside of the normal app navigation.
I've removed the jquery.history_remote script and now it works just great!
Dave
I have rather a complex UI. However, for the purpose of this question, let's say that there is a HTML table that renders UILayout1 by default (say default mode). There is a button that a user can use to toggle between the default mode and a preview mode (UILayout2)
When in preview mode, there are some columns in the table that are invisible and there are reordering of rows. I am using JS (jquery) on load to check the mode and change it accordingly.
The table and the toggle button are in UpdatePanels.
Functionally, everything works as expected. However, when a user toggles between default and preview mode or vice versa, there is this short time interval in which the the table renders in default and then JS runs to make changes.
This results in degraded UI experience. Are there any creative ways to avoid this "flicker"?
you can use DIVs or don't use update panel in your UI generation use any concept else
The problem is likely to be that your code is running on load. I'm assuming that you're doing this using the standard jQuery method of running code on load, and not using the window's onload event. In any case, even using jQuerys $(document).ready(...) will be too slow if you have a lot of other javascript files to load, as the .ready event isn't fired on the document until all javascript includes have loaded.
You should be able to work around the issue by including your code that modifies the table just after the html for the table in your page and not running it on load i.e. make sure you don't wrap it in $(document).ready(...);
For this approach to work, you will need to have all javascript required by the code which is modifying the table included earlier in the page.
If you have other non-essential javascript files included, you should try to include them later in the page.
I'm not 100% sure how being inside an update panel will affect it - you will need to make sure that your code is being re-triggered when the updatepanel updates, but I believe this should all happen automatically.
Presumably your UI is controlled by CSS? You might be able to get rid of the flickering by adding something like this at the start of your JavaScript or in the <head> of your HTML:
if (previewMode) {
document.documentElement.className = 'preview';
}
Then if you modify your CSS rules that apply to your preview mode to reflect the HTML element having the class="preview" to something like:
.preview table .defaultMode {
display:none;
}
hopefully your table should render correctly first time and will not need to be re-drawn.