we are trying to use OnNavigatedFrom and OnNavigatedTo but the "OnNavigatedTo" is not called when needed
ViewModelOne:
_navigationService.NavigateAsync("ViewModelPageTwo", useModalNavigation: false);
ViewModelTwo:
var parameters = new NavigationParameters()
{
{
"Pesquisa",
TextoPesquisa
},
{
"DataEnvioInicial",
DataEnvioInicio
},
{
"DataEnvioFim",
DataEnvioFim
},
{
"DataHistoricoInicio",
DataHistoricoInicio
},
{
"DataHistoricoFim",
DataHistoricoFim
},
{
"TodasAsCaixas",
PesquisaEmTodasCaixas
}
};
_navigationService.GoBackAsync(parameters);
The problem is that ViewModelOne -> OnNavigatedTo not trigger when GoBackAsync from ViewModelTwo
So what's happening is when you call GoBackAsync, you are actually going back to the TabbedPage, not the actual Tab. For now, you can implement INavigationAware on the actual TabbedPage, and then pass your parameters to the selected Tab's VM in the code-behind. Not optimal, but it will work for now. There is actually a discussion on the GitHub site talking about the various issues when dealing with TabbedPages and it's children during navigation. YOu can follow it here:
https://github.com/PrismLibrary/Prism/issues/650
Related
I have a fullCalendar widget created somewhere. I cannot change the code that initialize it. So I cannot add any callbacks in the first call.
Anything like this:
$(elem).fullCalendar({
complete: function () {
...
}
})
Actually creates a new fullCalendar instead of modifying the actual fullCalendar to change/add the complete callback.
Is there an other way to find out when events are loaded I was thinking about polling clientEvents but I realize that I could have no events in one month so I cannot expect the array to always have something in it.
By the way, it's fullCalendar 1.6.
You can define callbacks after the calendar object has been initialized, and to determine when all events have been rendered, use the eventAfterAllRender event. Here's how:
var calendar = $('#calendar').fullCalendar('getCalendar');
calendar.on('eventAfterAllRender', function(view) {
alert('all events rendered!');
});
Nevermind, this feature is only available starting in version 2.4.
Instead, you could poll the DOM for fullcalendar element existence, like this:
function checkForInit() {
if($(".fc-view").children().length) {
alert("initialized!");
} else {
setTimeout(function() {
checkForInit();
}, 10);
}
}
$(document).ready(function() {
checkForInit();
});
You can use eventAfterAllRender event, available from version 1.6:
$(elem).fullCalendar({
eventAfterAllRender: function (view) {
...
}
})
Ok I found a solution that seems to be working!
var waitPrint = true
function autoPrint() {
var elem = $('.fc')
var calendar = elem.data('fullCalendar')
console.log('Searching calendar')
if (calendar && waitPrint) {
waitPrint = false
console.log('Bund new event')
var _super = calendar.options.eventAfterAllRender
calendar.options.eventAfterAllRender = function (event, element, view) {
if (_super) {
_super.apply(this, arguments)
}
window.print()
}
} else if (waitPrint) {
setTimeout(autoPrint, 100)
}
}
autoPrint()
Here I'm polling for an element with the fc class. As soon as I find one, I check for the existence of the "data" named fullCalendar. If it returns a dict, then it means that the fullCalendar instance has been created. This is pretty much what Dane proposed for version 2.4 but this in 1.6 there is no getter. We have to get it ourselves. Luckily, it's stored in the data of the element and not in some other cryptic places.
Move on to the next step, fullCalendar isn't an eventEmitter in 1.x, but we still have access to options which seems to be just a reference to the options that were passed at first. I override the eventAfterAllRender. Call the method that was already defined if present and call my print method when it's done.
Technically from there, we can override almost any defined method from there. The only problem is that you have to do it faster than fullCalendar get initialized.
I believe that if we dig deeper, we could potentially patch the calendar library directly to remove the timing issues. Polling isn't very great.
Best Solution So far
var oldFullCalendar = $.fn.fullCalendar
function newFull(options) {
var _super_func = null
if (typeof options == 'string') {
oldFullCalendar.apply(this, arguments)
} else {
options = options || {}
if (options.loading) {
_super_func = options.loading
}
options.loading = function (loading) {
console.log(loading, 'loading')
if (_super_func) {
_super_func.apply(this, arguments)
}
if (!loading) {
window.print()
}
}
oldFullCalendar.apply(this, arguments)
}
}
$.fn.fullCalendar = newFull
The first solution could probably be improved by overriding loading instead. Since it's the method that notify when loading has been processed and which is also apparently called after the eventAfterAllRender callback.
I'm using popupMode: true on my Sign In page, and have a signInSuccess callback function on my Widget page:
var config = {
...
callbacks: {
signInSuccess: function(tokenString, accountInfo,
opt_signInSuccessUrl) {
console.log(JSON.stringify(accountInfo));
return true;
}
},
...
}
My function gets called, and the user gets signed-in in the original window, but the widget popup window does not close.
Is this a defect or am I missing something?
Yeah this behavior has been changed for popups when signInSuccess is provided. There were problems with the old behavior. The idea here is that when callback is provided, the developer wants to handle that on their own. The page is still closed automatically when no callback is provided. In your case you will need to close manually.
You can add this snippet before you return true:
if (window.opener) {
window.close();
}
I am working on a page having lot of input-controls and related divs. There are use-cases on this page where I am suppossed to show/hide the divs depending on the order of user clicking on input-controls in various follow-up screens.
Now the divs are all there in first load itself and by showing/hiding, the screen changes for the user. Now to show/hide I can use css and add view* class to .main content div depending on business logic.
ex.:
.main div{
display: none;
}
.main.view1 div.a,.main.view1 div.b,.main.view1 div.f{
display:block;
}
.main.view2 div.c,.main.view2 div.f {
display:block;
}
.main.view3 div.c,.main.view3 div.f {
display:block;
}
....etc
But this way the no. of css classes are getting unmanageable.
Please suggest if there is a better method I can use wherein it becomes easy to manage the user-flows. I think there are regions in marionette which can help me manage this. Please suggest the best way and elaborate if the answer is marionette.regions
You can model the application as a state machine to model complicated workflows.
To define a state machine:
Define all the states that your application can be in.
Define the set of actions that are allowed in each state. Each action will transition the state of the application from one state to another.
Write the business logic for each action which includes both persisting changes to the server and also changing the state of the views accordingly.
This design is similar to creating a DFA, but you can add extra behaviour according to your needs.
If this sounds too abstract, here's an example of a simple state machine.
Let's say you're building a simple login application.
Design the States and Actions
INITIAL_STATE: The user visits the page for the first time and both fields are empty. Let's say you only want to make the username visible, but not the password in this state. (Similar to the new Gmail workflow)
USERNAME_ENTRY_STATE: When the user types in the username and hits return, in this state, you want to display the username and hide the password. You can have onUsernameEntered as an action in this state.
PASSWORD_ENTRY_STATE: Now, the username view will be hidden and the password view will be shown. When the user hits return, you have to check if the usernames and passwords match. Let's call this action onPasswordEntered
AUTHENTICATED_STATE: When the server validates the username/password combination, let's say you want to show the home page. Let's call this action onAuthenticated
I have omitted handling the Authentication Failed case for now.
Design the Views:
In this case, we have the UsernameView and the PasswordView
Design the Models:
A single Auth model suffices for our example.
Design the Routes:
Check out the best practices for handling routes with Marionette. The state machine should be initialized in the login route.
Sample Pseudo-Code:
I've only shown the code relevant to managing the state machine. Rendering and event handling can be handled as usual;
var UsernameView = Backbone.View.extend({
initialize: function(options) {
this.stateMachine = options.stateMachine;
},
onUserNameEntered: function() {
username = //get username from DOM;
this.stateMachine.handleAction('onUserNameEntered', username)
},
show: function() {
//write logic to show the view
},
hide: function() {
//write logic to hide the view
}
});
var PasswordView = Backbone.View.extend({
initialize: function(options) {
this.stateMachine = options.stateMachine;
},
onPasswordEntered: function() {
password = //get password from DOM;
this.stateMachine.handleAction('onPasswordEntered', password)
},
show: function() {
//write logic to show the view
},
hide: function() {
//write logic to hide the view
}
});
Each state will have an entry function which will initialize the views and and exit function which will cleanup the views. Each state will also have functions corresponding to the valid actions in that state. For example:
var BaseState = function(options) {
this.stateMachine = options.stateMachine;
this.authModel = options.authModel;
};
var InitialState = BaseState.extend({
entry: function() {
//show the username view
// hide the password view
},
exit: function() {
//hide the username view
},
onUsernameEntered: function(attrs) {
this.authModel.set('username', attrs.username');
this.stateMachine.setState('PASSWORD_ENTRY_STATE');
}
});
Similarly, you can write code for other states.
Finally, the State Machine:
var StateMachine = function() {
this.authModel = new AuthModel;
this.usernameView = new UserNameView({stateMachine: this});
//and all the views
this.initialState = new InitialState({authModel: this.authModel, usernameView: this.usernameView});
//and similarly, all the states
this.currentState = this.initialState;
};
StateMachine.prototype = {
setState: function(stateCode) {
this.currentState.exit(); //exit from currentState;
this.currentState = this.getStateFromStateCode(stateCode);
this.currentState.entry();
},
handleAction: function(action, attrs) {
//check if action is valid for current state
if(actionValid) {
//call appropriate event handler in currentState
}
}
};
StateMachine.prototype.constructor = StateMachine;
For a simple application this seems to be an overkill. For complicated business logic, it is worth the effort. This design pattern automatically prevents cases such as double-clicking on a button, since you would have already moved on to the next state and the new state does not recognise the previous state's action.
Once you have built the state machine, other members of your team can just plug in their states and views and also can see the big picture in a single place.
Libraries such as Redux do some of the heavy-lifting shown here. So you may want to consider React + Redux + Immutable.js as well.
I have the following:
function activate(routeData) {
// make dataservice call, evaluate results here. If condition is met, reroute:
if (true){
router.navigateTo("#/someRoute");
}
alert ("should not be shown");
}
The alert is getting hit however, and then the view changes.
How do I fully navigate away from the current item and prevent any further code in that vm from being hit?
Update:
I tried using guardroute but I have to activate the viewModel to call the dataservice that returns the data that determines whether or not I should re-route. Using guardroute totally prevents the dataservice from getting called (since nothing in the activate function will get hit).
I also tried returning from the if block but this still loads the view / viewAttached / etc so the UX is glitchy.
The following worked for me in Durandal 2.0:
canActivate: function() {
if(condition)
return {redirect: 'otherRoute'};
return true;
}
activate: // Do your stuff
It's mentioned in the documentation: http://durandaljs.com/documentation/Using-The-Router.html
Here's #EisenbergEffect answer to a quite similar discussion in google groups.
Implement canActivate on your view model. Return a promise of false,
then chain with a redirect.
You might want to give #JosepfGabriel's example (discussion) a try in Durandal 1.2. Check the correct router syntax for your Durandal version, you might have to substitute it with something like router.navigateTo("#/YourHash", 'replace').
canActivate: function () {
return system.defer(function (dfd) {
//if step 2 has a problem
dfd.resolve(false);
})
.promise()
.then(function () { router.navigate("wizard/step1", { trigger: true, replace: true }); });
}
However this is NOT working in Durandal 2.0 and there's a feature request https://github.com/BlueSpire/Durandal/issues/203 for it.
You can't call redirect into the active method.
You can override the guardRoute method from router, to implement redirections.
You can do somehting like that:
router.guardRoute= function(routeInfo, params, instance){
if(someConditios){
return '#/someRoute'
}
}
You can return a promise, true, false, the route to redirect... You can find more information about that in the next link: http://durandaljs.com/documentation/Router/
Rainer's answer was pretty good and works for me adding this small fix.
Inside the then() block simply call the navigation like this
setTimeout(function() { router.navigateTo('#/YOUR DESTINATION'); }, 200);
that should fix your problem. The setTimeout does the trick. Without it the newly navigated page catches the old NavigationCancel from the previous one.
Adding a return in your if (true) block should fix this.
function activate(routeData) {
if (true){
router.navigateTo("#/someRoute");
return;
}
alert ("should not be shown");
}
I am using dojo datagrid to display my data. When the end user edit the cell values it should be updated in the server using ajax calls(when the focus goes out of the cell).
Else, I should have a Edit & update/cancel buttons for each row to handle the same feature.
But I don know how to place edit & update buttons inside the grid and capture their events.
By default dojo updates only local the store value(client side). how can I save the updated cell values into the server?
do we need to write any override methods to do so??
I am new to dojo. Any detailed explanation or sample codes would be much appreciated.
Could anyone lend a hand to solve this issue??
Thank you
Regards,
Raj
To be able to push the updates server-side, you've to override _saveCustom() or _saveEverything(). Here is a piece of code (a bit cleaned-up) I'm using to persist an update.
Note that the code below relies on the private _getModifiedItems() because the DataGrid accepts inline editions. If you do know the list of modified items (because the edition is done in a popup and you keep the item key somewhere), retreiving the modified item is simpler.
module.submitUpdates = function() {
var store = <from a variable local to the module>
if (store.isDirty() confirm("Updates to be persisted. Continue?")) {
store._saveCustom = function(saveCompleteCallback, saveFailedCallback) {
var modifiedItem = _getModifiedItems(store)[0];
dojo.xhrPost( {
headers: { "content-type": "application/json; charset=utf-8" },
content: dojo.toJson(modifiedItem),
handleAs: "json",
load: function(response) {
if (response !== null && response.success) {
saveCompleteCallback();
}
else {
saveFailedCallback(response);
}
},
error: saveFailedCallback,
url: "/API/<Object>"
});
};
store.save( {
onComplete : function() {
module.loadCachingRuleList();
},
onError : function(errorData, request) {
_reportUpdateFailure(errorData, errMsg);
}
});
}
};
Here is the code I use to get all updated items when the user is about to loose an updated DataGrid (because he leaves the page or because he wants to refresh the grid content).
Note that the following code was using Dojo 1.3. I haven't check if it's easier with Dojo 1.4... I hope that dojo.Stateful that's going to be introduced in Dojo 1.5 will simplify it, otherwise we'll have to wait for Dojo 1.6 ;)
var _getModifiedItems = function(store) {
var modifiedItems = [];
if (store !== null && store._pending !== null) {
if (store._pending._modifiedItems !== null) {
for (var modifiedItemKey in store._pending._modifiedItems) {
if (store._itemsByIdentity) {
modifiedItems.push(store._itemsByIdentity[modifiedItemKey]);
}
else {
modifiedItems.push(store._arrayOfAllItems[modifiedItemKey]);
}
}
}
if (store._pending._newItems !== null) {
for (var modifiedItemKey in store._pending._newItems) {
if (store._itemsByIdentity) {
modifiedItems.push(store._itemsByIdentity[modifiedItemKey]);
}
else {
modifiedItems.push(store._arrayOfAllItems[modifiedItemKey]);
}
}
}
}
return modifiedItems;
};
var _getDeletedItems = function(store) {
var deletedItems = [];
if (store !== null && store._pending !== null && store._pending._deletedItems !== null) {
for (var deletedItemKey in store._pending._deletedItems) {
if (store._itemsByIdentity) {
deletedItems.push(store._itemsByIdentity[deletedItemKey]);
}
else {
deletedItems.push(store._arrayOfAllItems[deletedItemKey]);
}
}
}
return deletedItems;
};
I hope this helps,
A+, Dom
This isn't a very detailed explanation but yes you should override the method that handles user data entries as I don't see an event for this. So basically create a new class that inherits from the data grid, find the method in the source code that handles the editing and override it to give it an extra action to post it back to the server. You'll want to call the datagrid's default action in that method too.
Some information here (that you probably are already aware of):
http://docs.dojocampus.org/dojox/grid/DataGrid#editing-data
I've extended Dojo's default components before, it's not hard. I find that it's always good to examine the Dojo source and to just be careful when upgrading Dojo to make sure new versions don't break existing features.
To avoid hacking your dojo library, just switch to the YUI2 data table; it's cell editor accepts the asyncsubmitter function that sends your edits to your sever
This is the description from documentation
asyncSubmitter
Function
Implementer defined function that can submit the input value to a server. This function must accept the arguments fnCallback and oNewValue. When the submission is complete, the function must also call fnCallback(bSuccess, oNewValue) to finish the save routine in the CellEditor. This function can also be used to perform extra validation or input value manipulation.
YUI2DataTable