Dynatree onDragOver and onDrop work perfectly in IE9, but only intermittently in Chrome - dynatree

I am trying to implement the drag and drop funcationality with the Dynatree plugin. It works completely as expected in IE 9. In Chrome, however, the functionality is intermittent. I have downloaded the latest .js files from the Dynatree web site, and also played around with the versions of jquery.js that I am referencing.
At first, I thought that in Chrome the onDragOver and onDrop functions that I had declared were simply not getting called. However, when I inserted console log statements, then launched the MVC project in which the Dynatree object was being rendered, I could see in the Chrome developer tools console monitor that the onDragStart function was always called without fail, but when I would drag the mouse around with the "attached" node, I could only get the onDragOver function to fire in what seemed like random spots. When I got the onDragOver to fire and actually "reference" or highlight one of the other nodes in the tree, the onDrop function would also work.
Ironically, this code below works perfectly in IE9. I can get it to work in Chrome, but only if I use it in a WebForms ASP.NET project. Now, I'm sure you're thinking, "Why not just use it in a WebForms project?". That remains a possibility (last resort), but with what we need to accomplish with saving changes to our database, the MVC will work much better for the other aspects of the site. The code below fairly closely follows one of the examples provided on the Dynatree home website.
Thanks for any help you can provide.
Update: I have discovered that it isn't that the onDragOver and onDrop functions are not being called. When viewed in Chrome using MVC, the dynatree is just very picky and sensitve to exactly where you click. This could entirely be a product of my json string, or some settings on Chrome. I just don't know yet. If I click to the left of the node, I can select it every time, and move it to where I want. I have to be very specific with where I drag it and drop it. In Chrome, in the web forms model, it seems as though the "areas" within which you can operate are simply much larger. ?
$(document).ready(function () {
$("#OrgTree").dynatree({
initAjax: {
url: $('#Path').val()
},
dnd: {
onDragStart: function (node) {
/** This function MUST be defined to enable dragging for the tree.
* Return false to cancel dragging of node.
*/
//alert(node);
logMsg("tree.onDragStart(%o)", node);
return true;
},
onDragOver: function (node, sourceNode, hitMode) {
/** Return false to disallow dropping this node. * */
logMsg("tree.onDragOver(%o, %o, %o)", node, sourceNode, hitMode);
// Prevent dropping a parent below it's own child
if (node.isDescendantOf(sourceNode)) {
return false;
}
// Prohibit creating children in non-folders (only sorting allowed)
//if (!node.data.isFolder && hitMode === "over") { return "after"; }
},
onDrop: function (node, sourceNode, hitMode, ui, draggable) {
/** This function MUST be defined to enable dropping of items on
* the tree.
*/
logMsg("tree.onDrop(%o, %o, %o)", node, sourceNode, hitMode);
if (node.isDescendantOf(sourceNode)) {
return false;
}
//alert(node, sourceNode, hitMode);
//sourceNode.expand();
sourceNode.move(node, hitMode);
},
onDragEnter: function (node, sourceNode) {
/** sourceNode may be null for non-dynatree droppables.
* Return false to disallow dropping on node. In this case
* onDragOver and onDragLeave are not called.
* Return 'over', 'before, or 'after' to force a hitMode.
* Return ['before', 'after'] to restrict available hitModes.
* Any other return value will calc the hitMode from the cursor position.
*/
// Prevent dropping a parent below another parent (only sort
// nodes under the same parent)
// Allowing dropping *over* a node will create a child of that node
if (node.isDescendantOf(sourceNode)) {
return false;
}
return ["before", "after", "over"];
}
}
});
})

I have found that the issue lies with the references to icon files and an older version of the jquery library being used. I'm still not sure why it wasn't an issue for IE, but was for chrome.
My theory on why the incorrect reference to the icon file was causing a problem was that when no icons were rendered on the Dynatree object, Chrome did not insert any "pixel address" on which to click. I realize that is not the correct term, but it is my theory. In IE, it did not seem to be a problem.
When I rendered the page after correcting the reference to the icon file, all worked as expected.

Related

Enquire.js: Don't get the purpose of "setup" handler

I don't quite get the idea behind enquire.js' "setup" handler.
Case:
I want to load content through ajax once when you're not in a small viewport (lt 600px).
Naturally I would do enquire.register('(min-width: 600px)', { setup: myFunction });.
Problem:
Now I tested this multiple times but the setup handler also gets fired when you're in a small screen, which totally eliminates the benefit of the setup handler imo, because you would want to only load the ajax content once you enter a viewport bigger than 600px, wouldn't you?
See example jsfiddle.
Conclusion:
So actually I wouldn't even need the setup handler because I simply could load the content outside the enquire register and would have the same effect. (Which of course isn't what I want...)
Can someone tell me if I just misunderstood the purpose of setup or is there something I'm missing?
Combine with the deferSetup flag to defer the setup callback until the first match. This example illustrates the feature:
enquire.register(someMediaQuery, {
setup : function() {
console.log("setup");
},
deferSetup : true,
match : function() {
console.log("match");
},
unmatch : function() {
console.log("unmatch");
}
});
You can see a working example here: http://wicky.nillia.ms/enquire.js/examples/defer-setup/

How to use store.filter / store.find with Ember-Data to implement infinite scrolling?

This was originally posted on discuss.emberjs.com. See:
http://discuss.emberjs.com/t/what-is-the-proper-use-of-store-filter-store-find-for-infinite-scrolling/3798/2
but that site seems to get worse and worse as far as quality of content these days so I'm hoping StackOverflow can rescue me.
Intent: Build a page in ember with ember-data implementing infinite scrolling.
Background Knowledge: Based on the emberjs.com api docs on ember-data, specifically the store.filter and store.find methods ( see: http://emberjs.com/api/data/classes/DS.Store.html#method_filter ) I should be able to set the model hook of a route to the promise of a store filter operation. The response of the promise should be a filtered record array which is a an array of items from the store filtered by a filter function which is suppose to be constantly updated whenever new items are pushed into the store. By combining this with the store.find method which will push items into the store, the filteredRecordArray should automatically update with the new items thus updating the model and resulting in new items showing on the page.
For instance, assume we have a Questions Route, Controller and a model of type Question.
App.QuestionsRoute = Ember.Route.extend({
model: function (urlParams) {
return this.get('store').filter('question', function (q) {
return true;
});
}
});
Then we have a controller with some method that will call store.find, this could be triggered by some event/action whether it be detecting scroll events or the user explicitly clicking to load more, regardless this method would be called to load more questions.
Example:
App.QuestionsController = Ember.ArrayController.extend({
...
loadMore: function (offset) {
return this.get('store').find('question', { skip: currentOffset});
}
...
});
And the template to render the items:
...
{{#each question in controller}}
{{question.title}}
{{/each}}
...
Notice, that with this method we do NOT have to add a function to the store.find promise which explicitly calls this.get('model').pushObjects(questions); In fact, trying to do that once you have already returned a filter record array to the model does not work. Either we manage the content of the model manually, or we let ember-data do the work and I would very much like to let Ember-data do the work.
This is is a very clean API; however, it does not seem to work they way I've written it. Based on the documentation I cannot see anything wrong.
Using the Ember-Inspector tool from chrome I can see that the new questions from the second find call are loaded into the store under the 'question' type but the page does not refresh until I change routes and come back. It seems like the is simply a problem with observers, which made me think that this would be a bug in Ember-Data, but I didn't want to jump to conclusions like that until I asked to see if I'm using Ember-Data as intended.
If someone doesn't know exactly what is wrong but knows how to use store.push/pushMany to recreate this scenario in a jsbin that would also help too. I'm just not familiar with how to use the lower level methods on the store.
Help is much appreciated.
I just made this pattern work for myself, but in the "traditional" way, i.e. without using store.filter().
I managed the "loadMore" part in the router itself :
actions: {
loadMore: function () {
var model = this.controller.get('model'), route = this;
if (!this.get('loading')) {
this.set('loading', true);
this.store.find('question', {offset: model.get('length')}).then(function (records) {
model.addObjects(records);
route.set('loading', false);
});
}
}
}
Since you already tried the traditional way (from what I see in your post on discuss), it seems that the key part is to use addObjects() instead of pushObjects() as you did.
For the records, here is the relevant part of my view to trigger the loadMore action:
didInsertElement: function() {
var controller = this.get('controller');
$(window).on('scroll', function() {
if ($(window).scrollTop() > $(document).height() - ($(window).height()*2)) {
controller.send('loadMore');
}
});
},
willDestroyElement: function() {
$(window).off('scroll');
}
I am now looking to move the loading property to the controller so that I get a nice loader for the user.

select2 scroll to error not working with jquery validation and asp.net mvc

Posting this here in case someone else has the same problem...
When using a select2 dropdown in a C# MVC4 site, the page is not scrolled to the correct position when validation fails. Validation as such works and error scrolling also works for other controls, just not select2's. The reason AFAICS is that select2 replaces the original select with it's own markup and then set the original select as display:none. jquery.validate then has no valid target to scroll to.
We are using twitter bootstrap for styling, but I don't think it has any impact on this problem.
The jquery.validate documentation (as well as many answers here on StackOverflow) suggests that you use $.validator.setDefaults to assign the invalidHandler, but I couldn't get this to work in asp.net (it does work for focusInvalid however), probably due to us using the MS unobtrusive library. Instead I used this code in my jquery ready handler:
$(function() {
$.validator.setDefaults({
focusInvalid: false
});
function scrollToError(error, validator) {
var elem = $(validator.errorList[0].element);
if (elem.length) {
if (elem.is(':visible'))
return elem.offset().top - 16;
elem = elem.prev($(".select2-container"));
if (elem.length) {
return elem.offset().top - 16;
}
}
return 0; // scroll to top if all else fails
}
$('form').bind('invalid-form.validate', function(error, validator) {
// fix scrolling and validation for select2
if (!validator.numberOfInvalids())
return;
$('html, body').animate({
scrollTop: scrollToError(error, validator)
}, 500);
});
...
I set focusInvalid to false to disable and avoid conflict with the standard scroll and focus behavior.
The bind() call is used instead of the invalidHandler option and is the same as used by the validate plugin.
scrollToError() selects the first invalid element and returns the position to scroll to, either a normal visible element or a previous item with the 'select2-container' class (i.e a select2 element) or top of page if all else fails.
Standard behavior (showing validation errors etc) still works as before.
Hope this helps someone and if you have a better solution I would be very interested in knowing about it.

Rally grid color rows based on model

I have a rallygrid that is configured to display two models: PortfolioItem/Feature and PortfolioItem/Rollup. I want to color them in the grid to differentiate them. I am not garunteed that they will alternate in the grid, or anything like that. I just want to apply a subtle color to the rollups to differentiate them visually.
Can anyone think of an easy way to achieve this?
I have tried:
viewConfig: {
getRowClass: function(record, index, rowParams, store) {
console.log('record',record); // nothing logged in console
console.log('index',index);
return 'colorCodeGrid'; // class never added
}
},
[EDIT]
viewConfig: {
stripeRows: false, // rows are no longer striped
getRowClass: function(record, index, rowParams, store) {
console.log('record',record); // still nothing logged in console
console.log('index',index);
return 'colorCodeGrid'; // class never added
}
},
It is strange to me that the viewConfig does correctly un-stripe the rows, but the getRowClass never gets called. I thought maybe just the viewConfig as a whole was not being used in the case of a rallygrid.
Your approach above with the viewConfig should work- I am going to file a defect on this. The root cause is that the Rally.ui.grid.GridView is blowing away the getRowClass function in its constructor (for internal browser testing purposes- ugghh) rather than checking if there was one supplied and calling that as well.
You can see it the source for the constructor here: https://developer.help.rallydev.com/apps/2.0rc1/doc/source/GridView.html#Rally-ui-grid-GridView
You should be able to work around it by just re-overriding the function before the view is rendered.
[EDIT by asker]
Added the following to the grid, and it worked:
listeners: {
beforerender: function(cmp) {
console.log('beforerender');
console.log('view',cmp);
cmp.view.getRowClass = function(record, index, rowParams, store) {
console.log('record',record); // still nothing logged in console
console.log('index',index);
return 'colorCodeGrid'; // class never added
};
}
},
UPDATE:
I just fixed this in the nightly build, so this should no longer be an issue in public sdk builds beginning with the next public release after 2.0rc2.

How do you recover the dijit registry after destroying it recursively?

I am working on an application and was doing something like this:
dojo.ready(
function(){ require['dojo/parser','dijit/registry','dojo/on'],function(.....){
//find a dijit and wrap it in event handling code.});
I was getting an error indicating that dojo was trying to register a widget with an id that was already in use. To solve the problem I entered this line of code:
//before finding the dijit destroy the existing registry.
However, logically this prevents the next line from working because now no widget exists to which I can connect an event. How can I recover the dijit ids?
The best solution is to find out why your code is trying to register a widget with an id that is already in use and change it to not to do so.
The #mschr's solution should work, but I would advise again using it, as it can break your code in many other places and you are likely to spend hours investigating strange behavior of your application.
Anyway, if you are willing to do it that way and automatically destroy widgets with the same ID, do not override registry.add() method. You could do it, but it does not mean, you should do it (especially in programming). Employ dojo/aspect instead to call a function that will destroy the widget with the same ID before registry.add() is called:
require([
"dojo/aspect",
"dijit/registry"
], function(
aspect,
registry
) {
aspect.before(registry, "add", function(widget) {
if(registry.byId(widget.id)) {
registry.byId(widget.id).destroy();
// this warning can save you hours of debugging:
console.warn("Widget with id==" + widget.id + " was destroyed to register a widget with the same id.");
}
return [widget];
});
});
I was myself curious how to accomplish #mschr solution without that override, so I created an jsFiddle to experiment: http://jsfiddle.net/phusick/feXVT/
What happens once you register a dijit is the following; it is referenced by the dijit.registry._hash:
function (widget) {
if (hash[widget.id]) {
throw new Error("Tried to register widget with id==" + widget.id + " but that id is already registered");
}
hash[widget.id] = widget;
this.length++;
}
Now, every now and then you would have a contentpane in which you would put a widget programatically (programatically, hence dojo.parser handles cpane.unload and derefences / destroys parser-instantiated widgets).
When this happens, you need to hook onto some form of 'unload', like, when your call cpane.set('content' foo) or cpane.set('href', bar). Hook is needed to destroy and unregister the instances you keep of widgets - otherwise you would have a memoryleak in your program.
Normally, once an object has no references anywhere - it will get cleaned out of memory however with complex objects such as a widget might be, 'class-variables' often have reference to something _outside _widget scope which flags the widget unsafe to delete to the garbage collector... Once you get this point, you will know to perform proper lifecycles, yet not before the concept is fully understood..
What you could do is to override the dijit.registry with your own handler and have any widgets that are doublets destroyed automatically like so:
// pull in registry in-sync and with global scoped
// accees (aka dijit.registry instead of dj_reg)
require({
async:false,
publishRequireResult:true
}, [
"dijit.registry"
], function(dj_reg) {
dijit.registry.add = function(widget) {
// lets change this bit
if (this._hash[widget.id]) {
this._hash[widget.id].destroy(); // optinally destroyRecursively
this.remove(widget.id)
}
this._hash[widget.id] = widget;
this.length++;
}
});