I am working on a project in which we load two models. Loaded two models opened in the same viewer. At the moment I am looking for a way to establish transparency or hide elements.
For some reason, the hide and isolate methods work on one model, although I am passing the dbId elements of the two models.
I was advised to use the enumNodeFragments method, but in my case it is always undefined, it simply does not exist. I've tried a lot of options, so that this method has appeared, but it was all in vain.
I would like to ask for advice on how I can find this method.
By the way, let me say that for me the most important thing is to find a way to hide the elements of the two models.
Like we discussed in the other thread this method is only available after the geometry data of the model is loaded - Viewer needs to tell whether the model is suitable for node fragment enumeration before it exposes the method:
viewer.addEventListener(Autodesk.Viewing.GEOMETRY_LOADED_EVENT,()=> viewer.model.getData().instanceTree.enumNodeFragments(dbid, fragId => console.log(fragId)))
See live code here.
Related
Yes I know there is a plugin called Backbone-Relational but I have a serious problem with its fetchRelated function which, in my opinion, renders it useless for me.
So I was wondering if there are any alternatives? Or do we even need plugins like Backbone-Relational at all? How would you handle following scenario with pure Backbone:
Let's say we have two Backbone models: Company and Person. A Company instance can have many Persons. So company.get('employees') will return an array of Person IDs. If I want to get details of related employees, I'll have to iterate over the array and fetch() each of the Persons from server. But what if those Person instances have been already downloaded? Is there a clean way to make sure that there is no redundancy?
May be we can maintain a Collection for each model and dump every instance we download into it. Then we can download an instance only when it is not present in the Collection. But I think it will make code look horrible.
So please share your experience guys. Thanks!
As you suggested, I would give my Company model a Persons attribute. But you seem to forget collections also have a fetch method (as well as many other methods you'd find pretty useful, as the get method).
Also, as a last thing, I'd like to quote Backbone's doc (regarding the fetch method of Collections):
"Note that fetch should not be used to populate collections on page load — all models needed at load time should already be bootstrapped in to place. fetch is intended for lazily-loading models for interfaces that are not needed immediately: for example, documents with collections of notes that may be toggled open and closed."
I am wondering how to structure a KnockoutJS application the right way.
The official documentation almost always uses just one single ViewModel!
After only a few implemented functions my code became very confusing and coming from an object-oriented background I am very allergic to architecture like that. So there must be a better solution.
Being not very experienced with JavaScript I was searching Stackoverflow and found those three options. So I tried the first two options and I am not happy with them:
Having multiple ViewModels like here.
I find it very difficult to decide what DOM-element gets what ViewModel. Also there were several functions called from outside the DOM-element. Maybe I used too little ViewModels with this kind of architecture but communicating between ViewModels seemed to be different and somehow shouldn't be necessary I hope. So how to do that properly?
Having sub views and utilizing the with binding (the second option from those three).
This was my preferred type of architecture because you can have document-wide bindings out of one view model but you can also structure your code into sub-chunks and bind them to wherever you want by using the with binding. This option though requires object literals instead of functions, which are inferior as described in this answer.
I haven't tried method three because it seems a little overkill and also uses object literals.
So is there a method to structure my code and also have full control without using object literals?
I hope this was not too confusing :-P
For any of the options that you mentioned, you do not need to use object literals. The samples just used them to simplify the code. You can choose to create the individual view models in any way that you see fit.
For example in #3, you can use a constructor function like: http://jsfiddle.net/rniemeyer/PctJz/149/. Of course, the actual data would get passed into the function rather than being static. Same with #2, you just would have it wrapped in the "View" object.
I need support for collections in spine.js. I know that spine.js doesn't support this at the moment - not sure if it ever will.
Has anybody added this feature or know the best way to go about implementing it?
This feature is built in.
Collections are just class methods on your model. The recommended way then is to simply add those few methods to your model.
If you need a different class for everything related to a collection (because you are used to ir ot something) you can simply create a new one that inherits from the original model and add the classmethods there.
sample: (check the console output)
http://jsfiddle.net/SpoBo/vBtKC/
I could have just as easily moved the published class method to the Post model and all would have worked as well without the need of an extra PostCollection class. Your choice :)
I am just starting out with backbone and am trying to set up a view which has a question list. To the left of the list I have four filters, to filter the list by language, country, status, and study. The list and each of the filters are loaded into their own collections.
My idea was to make this one view with multiple collections, but I wonder if this is best practice in backbone since all the examples I have seen only have one collection per view.
Another idea was to break in into two views with one being responsible for the filters and then a child view being responsible only for the list of questions.
Or, is it more backbone style to drop all of the collections into a model and then pass that model to my view like it mentions here: http://documentcloud.github.com/backbone/#FAQ-nested
Thanks for your ideas.
Yes. Theoretically a view can encompass any number of inner objects/collections. It generally makes good sense to have views be as discrete as possible, but there could be reasons to wrap more than one thing in a single view.
This is all a matter of design. I don't see what creating a container model as a bucket for your collections buys you.
Don't be too concerned with the absolute best way. Sometimes it takes walking a little down the wrong path to figure out the better ways for your particular project.
I think it's completely legit to pass more than one model or collection to a view - when appropriate.
Passing a model or collection to a view constructor will automatically appended that object to the view instance (so it's in this.model or this.collection) but you can also pass other data such as extra collections and they will be located in the options object (accessible from within your view as this.options.countries, etc.). Your views initialize method, if it exists, will also be passed this object.
Not sure of best practices but if you can break it into views then its good. Otherwise you'll be better off creating a view model with multiple collections in it and use them in the view.
I've recently started using Backbone.js. I like the architecture, in terms of features it's almost exactly what I need...
... However I found the following caveats:
For Collections get means something different than for Models. There is no set. Attributes should be accessed in a regular way. I find it rather inconsistent. It's easy to confuse models and collections sometimes. Is there anything that can be done to overcome this?
Assigning initial values inside Model.extend doesn't always work. For example assigning url will not override the default behaviour. This can only be achieved through a call to set() method. Again very error prone.
I still don't know whether it's required to use get/set inside initialize() call.
I don't understand why I can't just call _.bindAll(this) inside initialize() and I have to list specific function names to be bound like this: _.bindAll(this, firstFunc, secondFunc, ...). This is not very DRY.
I would like to know: what are the best practices regarding the mentioned situations? What do you do to make the framework more consistent - any monkey patching? Am I doing anything wrong / against the convention?
I'd be grateful for any good real world examples. I did find this: http://documentcloud.github.com/backbone/docs/todos.html and http://liquidmedia.ca/blog/2011/01/backbone-js-part-1/ and those don't address any of the mentioned problems. In fact they just present the simplest ideas and absolutely no border cases, so anything more complicated could be useful.
EDIT:
Ok, and there is one more fundamental think I don't understand:
Am I ever allowed to place additional attributes on extension like this: var SomeModel = Backbone.Model.extend({ myattribute: myvalue }) ?
If so, then why don't subsequent calls to new SomeModel().get("myattribute") work ?
What exactly is this inside initialize() ? Is it model class or model instance ?
EDIT(2):
Well, I found this: http://maccman.github.com/spine/. It looks like Backbone.js 2.0, shares a similar name too :). Haven't tested it yet, which might be a bit of a show stopper, as the library is very recent. However from the docs side of things it looks very promissing. It gets rid of most of the problems that I found, it simplifies the API, it even gets rid of the dependency on underscore.js which for a library is a good thing. I'll post my further findings here.
Ok, I think I can say it quite confidently now: Backbone is dead, long live Spine.
Spine isn't exactly a fork of Backbone. It is however very similar and clearly inspired by some of the design decisions. It could be said that the author tried to retain as much as it was possible the original backbone API, getting rid of everything unnecessary or illogical. I find it also easier to extend. The list of changes includes among other things:
Getting rid of the dreaded Collections. "class methods" are used instead,
Getting most out of js prototypical nature (i.e. no get/set is needed). Attributes are accessed directly. An explicit call to save() is required in order to trigger an event.
Views and Controllers are now merged into new type of Controllers together whose purpose is to respond to DOM events and bind to model events.
The name :)
I find those design decisions coherent and sensible.
The reason there is no 'set' for Collections is because Collections are not arrays, they are sets, which are potentially ordered. The only supported way to place an element at a particular position is to add it to the collection and then sort the collection.