I'm new to html5. I want to bind backbone collection to DOM element using rivets without extending backbone view. I got code snippets like extending adapter, using rivets.bind but i dont know how to organize everything. Can someone explain me how to achieve this in steps?
Thanks in Advance
Update: We can do this if we follow the example provided in the link of the accepted answer.
what you want to bind is the View, not the collection. The Collection is just data, an array of models if you wish. The View is what responds to user interaction, and that's where your rivets binding will be handled.
Check out Backbone.Marionette framework as its specialized CollectionView simplifies this even further, although you may go with a standard Backbone.View too.
Related
I am trying to replicate a part of demo shown here using autodesk-forge-viewer api. Particularly, I am not able to find code snippet around how can I do navigation for a particular area of 3D model. For example, if render 3D model is house, I require that If a click on "Bed Room" which is a link somewhere in browser, 3D rendered model should show me that "Bed Room". In sample app shown, they are providing the same as a feature of "Model Browser".
Could anyone please help me with that?
You first need to know the dbId's of the nodes you are interested in, most viewer API methods take dbIds as input. You get those either by listening to selection events, see that post, or by parsing the instance tree and checking the properties of the nodes to see if those are the ones you looking for.
You can then use methods such as viewer.fitToView([dbIds]), viewer.hide([dbIds]), viewer.show([dbIds]) ... Here is another article that might be useful: Hidding completely viewer nodes (no ghosting).
Hope that helps.
In my Windows Store XAML app I’m using the TreeView control from the WinRTXamlToolkit and I’m attempting to two-way bind the SelectedItem property to a property on a ViewModel.
Out of the box, the SelectedItem property is read only and this makes sense because the control supports Virtualization.
I have seen some folk work around this with things like attached properties, helper methods and so forth, a great example of which is seen in this question
WPF MVVM TreeView SelectedItem
But all of the questions/solutions are not based on WinRT and all of my attempts to rework the solution code for a WinRT app have proven fruitless.
So, my question is, is this possible in a WinRT app? What am I missing?
Thanks
I'd skip trying to come up with a bindable property globally for the view model and instead use the IsSelectedBindingPath and IsExpandedBindingPath properties of the TreeView as in the debugging tools' example of the control's usage. Then when you want to select/expand an item from the view model - use a method similar to SelectItem() in my view model where I essentially set IsExpanded/IsSelected to true in item/node view models throughout the path from the root of the view model tree and load the content of the tree if the nodes in the expected path do not exist.
Suppose I have a setting in NSuserdefaults that should affect a property for a lot (but not all) UIView objects, for example the font size.
The setting can also be changed from a 'main' viewcontroller and should be 'distributed' to UILabel objects that live in a UIView in a UITableviewcell inside a UITableView inside a UINavigationController inside a UISplitviewController and so on...
If I create this property on all levels of the controller and view hierarchy, and set the property when the property in the parent is set, this costs a lot of code.
Apple seems to prefer this pattern to manage the managedObjectContext by handing it to the child controller along the chain.
But this seems like overkill. Lot of code is just for passing around the value of the property, while nothing is done with it. I do however use this pattern to set properties in all subviews of a view at once (by recursively walking through all subviews).
Delegation seems to be just as bad, except maybe not if the delegate would be top level parent view controller. But then I would be passing the delegate around to all child view controllers.
Should I go with Notifications instead? I already have a controller listening to (all) changes in the NSUserDefaults via the NSUserDefaultsDidChangeNotification. Should that controller post a specific notification when my setting is changed? In that case, who should listen to it? Should it be the view controller that is responsible for the views involved?
After some more reading, I found advise in the book Cocoa Design Patterns from Buck / Yacktman, as they state:
As a general rule, use notifications when there are potentially many objects that may observe the notification. Use delegates when exactly one object is given an opportunity to influence or react to changes as they are happening.
So notifications is the answer.
I am using the URL logic for creating a dynamic Tree in Flex using action script. However the output is not properly shown (Object name is shown instead of Label).
Code is available in above mentioned URL.
Please help.
Write a correct toString() implementation of your DataTreeNode, so it would have a proper display in this tree.
An example: Provided the class DataTreeNode has a data:Object field, and this object has a urlToDisplay:String property that you want displayed. Do like this:
override public function toString():String {
if (!data) return '[null]';
return data.urlToDisplay;
}
If you only rely on simple Objects or data classes, you can use the tree's labelField or labelFunction in order to read and/or format data, which is passed to the renderer. There are no new item renderer classes needed.
New renderer should be compatible with these functions!
On a site note: item renderer are not "mostly just simple MXML classes", they are component instances. It doesn't matter how there are implemented. There are best practises like avoiding data bindings in item renderers, that's why it is common to use the markup for drawing, but implementing the views behaviour according to the Flex component live cycle. you might want to read about it in the documentation, because it is a necessary read for a Flex developer.
You will have to write an ItemRenderer that tells your tree how it should display the components. ItemRenderers are mostly just simple MXML classes that access one item each and display the data in any way you want. You will have to assign the ItemRenderer to your component.
See this article:
http://help.adobe.com/en_US/flex/using/WS03d33b8076db57b9-23c04461124bbeca597-8000.html
I just started to study the Model View Controller pattern. I now understand the basic usage of MVC, but when i tried to implement MVC in a simple test, i ran into a problem. Ofcoarse I could easily adjust the code so it works, but I wish to learn how to correctly implement the MVC pattern.
The test:
I used actionscript 3 to make a simple program. It consist of a turret, and a mouseclick. The turret is in the middle of the screen. When I click anywhere the turret rotates towards the point where I clicked. Both the mouse and the turret have their own model,view and controller. When I click, the MouseModel changes correctly. But for the actual TurretView to respond, the TurretModel must change its rotation variable and send out an event.
The question is who responds to the MouseModel event?
/------->MouseControl------\
/ \
MouseView ?<---MouseModel
TurretView <------------------TurretModel
TurretControl
I figured its best not to have MouseModel directly influence TurretModel or TurretControl, because this would require them to be an eventListener. Making TurretView listen to the MouseModel, and then tell TurretControl to adjust TurretModel, after wich TurretView can update trough a TurretModel event looks like a lot of extra code for a simple task. Also I'd rather not have MouseControl affect TurretModel, this would break the flexibility of the mouse as input for future classes.
Ow, also in which class do I put the code for the angle calculation?
Thanks in advance
Remember that the goal with MVC is primarily the separation of Model and View, and the Controller can serve as the communicator between the two.
Unless you are planning on storing each action that occurs (clicking, rotating, etc.), there is no real need for an action (in this situation) to send data to the Model. Everything you'd like to do should be easily handled with the Controller. So the flow would be:
Mouse click
Event is fired to trigger a command (in the Controller), passing along the mouse location
The command calculates the turret's rotation
The command tells the View to rotate the turret
This is, of course, my suggestion based off of your example. In truth, depending on the project, the above flow could easily change (for instance, in this situation it seems good to do rotation calculation in the command, but in other situations that may not make as much sense). Look at MVC as a goal - you're trying to separate these elements as much as possible, but there is no 100% "works-every-time" way to do it.
Robotlegs, a popular MVC framework, has a great diagram on their site showing how they tackled MVC:
http://www.robotlegs.org/diagram/
I'm not advertising that you NEED to use Robotlegs (it's good, but there's plenty of other alternatives), but they definitely made a pretty diagram :)
You should have one model, which then has pieces in it that you are currently calling MouseModel and TurretModel. You can either keep those names and breakdowns, or do something else once you have a better "handle" on what needs to be done.
The View that is tracking the mouse clicks should dispatch an event that your Controller component catches to update the TurretModel (at this point, there's probably no need for a MouseModel). Your TurretView can then update itself based on the TurretModel, or the Controller can update the TurretView based on the new value. This will depend on how you have it wired.
Usin a Framework such as Robotlegs can help you figure out all the ins and outs of this process, and I've heard that this book http://shop.oreilly.com/product/0636920021216.do provides a great explanation of MVC, even if you don't choose to use Robotlegs after you read it.