Could any one please give a full example of how dispose and destruct are working in qooxdoo 1.6 ? , I can't find any good example in the qooxdoo demos or documentation.
thanks in advise .
Disposal and destruction are in reality the two sides of the same coin: Disposal is the act of destructing objects. Their difference might become clearer to you by thinking of __destruct() as an onDispose() method.
As a rule of thumb, any class that creates QX objects is responsible for their proper destruction. Normally this is done the class' destructor, but may happen at any time depending on your business logic.
Disposal is done via the (ex.)
this._disposeObjects("_buttonOk", "_buttonCancel");
this._disposeArray("_children");
this._disposeMap("_registry");
calls. Some classes may provide explocit methods for their destruction, as in qx.ui.core.Widget
You don't need to implement dispose if you work with object. Only destruct is needed, and not for everything (see above to catch which one you should delete, which one you don't need to)
It will looks like this :
qx.Class.define("q.view.Home"),{
extend : qx.ui.core.Widget,
construct:function(){
this.base(arguments);
},
members:{
__qooxdoo_object:null
},
destruct:function(){
this._disposeObjects("__qooxdoo_object");
}
});
As simple as this.
On the memory management link : this is extremely important : "qx.disposerDebugLevel" : "2"
It will automatically report (on firebug for example) object who are not properly destroyed.
So you will be able to know exactly what you should delete, what is deleted in a proper way.
Also, imagine this, you got a container (Composite for example, or anything) with 5 children and you want to empty the content but not the container, you should do like that :
(according container is the parent element of all children)
var childrenList = container.removeAll();
for(var i=0; i<childrenList.length; ++i){
childrenList[i].dispose();
}
If you only dispose objet for some reason i don't know the Widget class (in qooxdoo framework) sometimes raise error. If you only removeAll, it will not dispose children but only remove them.
If you do both (dispose and removeAll), you will have no problem and children properly disposed.
Maybe the document in the qooxdoo manual about memory management could be helpful:
http://manual.qooxdoo.org/devel/pages/development/memory_management.html
Related
I am relatively newer with Angular so please excuse my mistakes, if any. I have to modify and use this treeview directive from NgModules. It's code looks promising but I have to modify it a little bit to add the functionality of add/ delete or modify items.
Plunker
I was previously using jQuery to create my treeview and have accomplished all the relevant tasks. But since I decided to shift to Angular, I have to do it the angular way.
So as far as I could understand this directive uses nested recursive directive to create the tree, which is an efficient way to do it. It works fine, but I would have some 3000-4000 items to show in my treeview. So when I do that with this code it slows down the screen and consumes much memory due to the many watch expressions (5-7 per item).
Plunker
I have tried one time binding in ng-repeat with :: notation. That has helped a lot but now I couldn't implement my add or update methods. Is there any way I could accomplish this?
<li data-ng-repeat="node in ::' + treeModel + '">
https://plnkr.co/edit/KwnvyslibWd1dmIXxBYU?p=preview
You already had the selected node in the scope, so simply push the new node into it's children array.
$scope.AddNode = function(NewNode)
{
NewNode = {"roleName" : NewNode , "roleId" : "role11", "children" : []};
$scope.mytree.currentNode.children.push(NewNode);
};
edit: As name suggest - it is one time binding, so adding/removing won't work here. I think it's only normal that browser get's a bit stuck when trying to display such amount of data once. Instead, you could add nodes by bits, say 20 a step. Or you could check out other libraries as well. This one gives you the option to display array of nodes collapsed at first.
I cannot really pinpoint whether the issue is with Ember or Ember data, or if it's even an issue, but here's what happens:
Let's say you've got your model called tell_me_a_story. This will be the name that your JSON should provide, should you be using ActiveModelAdapter.
Regardless, when Ember or Ember Data process it internally, it'll camelize it and it becomes tellMeAStory, correctly indicating that "A" and "Story" are two separate words.
However, when internally it is decamelized to lookup for the model, the decamelize function will convert it into tell_me_astory.
This final behavior seems flawed to me, but when looking at the tests that derived this behavior, it is actually intended to manage acronyms in that fashion. (Compare the following example with the "innerHtml" that I would expect for camel casing multi-letter acronyms.)
QUnit.test("converts a camelized string into all lower case separated by underscores.", function() {
deepEqual(decamelize('innerHTML'), 'inner_html');
if (Ember.EXTEND_PROTOTYPES) {
deepEqual('innerHTML'.decamelize(), 'inner_html');
}
});
(Source in Ember Runtime)
So, which is the correct way to use single-letter words in models with Ember? Are they even supported?
Here's an example of what I'm trying to do:
// this comes from a separate data source, e.g. REST APIs
var myModelName = 'tell_me_a_story';
// this line will throw if the model file is named "tell-me-a-story"
if (!store.getById(myModelName, 1)) {
// this line will throw if the model file is named "tell-me-astory"
store.pushPayload(myModelName, myObject);
}
You can override the stores _normalizeTypeKey then alter the camelCase behaviour to become what you want (e.g. dasherized or just fix this one case).
You can also override the serialisers typeForRoot when going the other way - this lets you tell ember what the model key is (e.g. tellMeAStory) for a particular key in your data (e.g. tell_me_a_story).
It appears there is work underway to make everything work like the container does (which is dasherized)
I have a requirement to "nag" a user about unsaved changes when they switch between different Backbone collection models (by clicking on a table row). I've googled for "check backbone model dirty data" (for instance) and not found anything definitive.
I accomplished this using underscore's "some" and isEqual functionality, in a manner such as the following, "some()" being sufficient to determine if there are any un-saved changes (as opposed to what those precise changes might be), in particular because the model attribute is actually an array of objects.
var anyDirty = _.some(myCollection.models, function(model) {
return !_.isEqual(model.get('nodes'), model.previousAttributes()['nodes]);
});
I am new to Backbone and am wondering if this is an accepted sort of approach for adhoc checking for dirty model data. Or, does Backbone provide some sort of built in functionality for this purpose, that my initial attempts at googling did not reveal?
I have another attribute I need to monitor in addition to 'nodes', so I'm switching to using changedAttributes(): http://backbonejs.org/#Model-changedAttributes:
var anyDirty = _.some(myCollection.models, function(model) {
return model.changedAttributes();
});
What may make this an imperfect solution is that it seems like it will return an object of changedAttributes even if the attribute got changed back to it's original value. So it almost seems that what I need in the long run is to take a snapshot of the original data and compare against that. Still though, using model.changedAttributes() is a more concise alternative to what I first posted.
I'm creating an invitation dialog that allows users to enter emails. Currently in the model I am creating an array to hold the emails:
initialize : function() {
this.model.set({
invite_email_array : new Array()
});
}
And then I'm adding/removing items in the view like so:
this.model.get('invite_email_array').push('email#domain.com');
Then problem is the binder is not being triggered when I either add or remove an email from the model. Here is my binder:
binder : function() {
model.on("change:invite_email_array", onInviteEmailArrayChange() )
}
The only way I was able to get the binding to trigger was to trigger it manually when I make updates.. an ugly hack
this.model.trigger("change:invite_email_array");
Any suggestions on a better way to maintain a list of emails and then be able to bind to the object on add/removes?
Thanks
In the example you give, you're bypassing set by altering the array directly. In order to trigger the change, you would need to set the altered array after pushing the new e-mail. Something to the effect of:
var arr = _.clone(this.model.get('invite_email_array'));
arr.push('email#domain.com');
this.model.set({ invite_email_array: arr });
As soon as you've introduced an array, however, it may be worth considering whether the view's design is really reflecting its intent. Collections (or arrays) of anything often signal that it's time to consider simplifying models or views. Even though a single e-mail seems too trivial assign to its own view/model, it may make sense to track an array of e-mails as a collection of "invitation" views and watch for changes accordingly.
I am developing a front end request/data management system in order to clean up/organize my API calls/refactor how I interface with my backend platform. I am extending the jquery ajax api call to interface with it and I am looking for some advice on where to stick api-specific implementation.
please keep in mind this is a web-application platform and I am trying to make it easier to manage front-end components
The goal is to take defining a request from something like...
var requestObj = new Object();
requestObj.callback = function(responseObj){deleteUserComplete(responseObj); };
requestObj[0] = new Object();
requestObj[0].module = "usermanager";
requestObj[0].context = "#someTable";
requestObj[0].action = "DELETE_USER";
requestObj[0].dataObj = new Object();
requestObj[0].dataObj.userId = $("#ui-tabs-4 .az-switch-panel-off input[name$=userId]").val();
To...
$("button.apiSubmit").apiManager('submitApi');
or
var options = {};
options.callback = someFunction;
options.context = "#someTable";
//etc...
$("button.apiSubmit").apiManager('submitApi', options);
I'm sure you get the idea... but i want to move the ugly request object creation to a factory-type object (mainly just processing forms into objects my backend understands) and moving the api-specific implementation (module, action, context etc) to the markup.
Now for the question(s)...
1) What are the benefits/pitfalls of moving my api-specific request information to the markup?
2) (again, pretty much convinced moving request info to the markup is the right move) class tags or html5 data attributes (x-browser isn't an issue... they are internal apps)?
EX: of class attributes would be... class="apiButton apiButton-module-MODULE_NAME apiButton-action-ACTION_NAME" - obviously a bit ugly... but manageable straightforward way to go about htis.
3) Are there any alternatives to making my api requests more reusable/easier to read? It's the only way I communicate with php so it's very... very important this system is solid.
1) Whereas I somewhat agree with Marcel Korpel on using HTML5 data attributes, I think that using the markup explicitly presents a couple potential problems: first off you are exposing your API/backend internals to the end-user, which is never ideal and secondly its kind of volatile because it could be easily changed (firebug, js) and mess up the behaviour associated with that element.
2) The more elegant (but slightly harder to implement method) would be to use jQuery's .data() method to store related information - this way you keep your markup clean and still have the flexibility of storing as much information as you want related to the element. It is also "hidden" from the end-user (sure firebug/js can access it but it's slightly harder to come by than right in the markup). There are basically 2 ways I can think of how you could implement this: -1 - if you are creating the markup dynamically then wrap the element in a jQuery object and apply the metadata before inserting it into the DOM or -2- if it is being created with PHP you could store it as a serialized string in "rel" or "rev" or someother little-used attribute and then use jQuery to grab it, store in metadata and clear the attribute.
3) However, now that I think about it, whereas using .data() is more elegant, I guess it doesn't make it all the more easier to understand because you are effectively hiding away applications internals. Perhaps you could implement getter/setters to retrieve the metadata or something along those lines.