I'm developing a tree menu using Om Next by nesting multiple instances of the same component ((defui Tree...). I can recursively build the tree by passing different properties, so the initial rendering is fine.
But, re-rendering items upon the state change is problematic since they share the same query and the params. But, if I can have different query parameters in different component instances they will be served with appropriate properties.
My understanding is, the query and the parameters are linked to the Component rather the individual instances. Therefore, trying to update parameters using om-next/set-query! didn't work here.
What is the idiomatic way of handling such a scenario?
Can we do a workaround with om/factory?
(Please pardon me if I'm suffering from a misunderstanding of fundamentals here.)
Related
Continuing to work on my port of a CakePHP 1.3 app to 3.0, and have run into another issue. I have a number of areas where functionality varies based on certain settings, and I have previously used a modular component approach. For example, Leagues can have round-robin, ladder or tournament scheduling. This impacts on the scheduling algorithm itself, such that there are different settings required to configure each type, but also dictates the way standings are rendered, ties are broken, etc. (This is just one of 10 areas where I have something similar, though not all of these suffer from the problem below.)
My solution to this in the past was to create a LeagueComponent with a base implementation, and then extend that class as LeagueRoundRobinComponent, LeagueLadderComponent and LeagueTournamentComponent. When controllers need to do anything algorithm-specific, they check the schedule_type field in the leagues table, create the appropriate component, and call functions in it. This still works just fine.
I mentioned that this also affects views. The old solution for this was to pass the league component object from the controller to the view via $this->set. The view can then query it for various functionality. This is admittedly a bit kludgy, but the obvious alternative seems to be extracting all the info the view might require and setting it all individually, which doesn't seem to me to be a lot better. If there's a better option, I'm open to it, but I'm not overly concerned about this at the moment.
The problem I've encountered is when tables need to get some of that component info. The issue at hand is when I am saving my add/edit form and need to deal with the custom settings. In order to be as flexible as possible for the future, I don't have all of these possible setting fields represented in the database, but rather serialize them into a single "custom" column. (Reading this all works quite nicely with a custom constructor and getters.) I had previously done this by loading the component from the beforeSave function in the League model, calling the function that returns the list of schedule-specific settings, extracting those values and serializing them. But with the changes to component access in 3.0, it seems I can no longer create the component in my new beforeMarshal function.
I suppose the controller could "pass" the component to the table by setting it as a property, but that feels like a major kludge, and there must be a better way. It doesn't seem like extending the table class is a good solution, because that would horribly complicate associations. I don't think that custom types are the solution, as I don't see how they'd access a component either. I'm leaning towards passing just the list of fields from the controller to the model, that's more of a "configuration" method. Speaking of configuration, I suppose it could all just go into the central Configure data store, but that's always felt to me like somewhere that you only put "small" data. I'm wondering if there's a better design pattern I could follow that would let the table continue to take care of these implementation details on its own without the controller needing to get involved; if at some point I decide to change from the serialized method to adding all of the possible columns, it would be nice to have those changes restricted to the table class.
Oh, and keep in mind that this list of custom settings is needed in both a view and the table, so whatever solution is proposed will ideally provide a way for both of them to access it, rather than requiring duplication of code.
I'm working on a XAML-based Windows Phone 8.1 project. My MainPage has a Pivot control, the first item of which is designed to be a "dashboard" of some sort, combining multiple kinds of data such as events and to-dos.
For this particular purpose I have an Event and a To-do model classes (not the actual name, but you get the idea), as I am using MVVMLight to run the show.
I have currently set up a ListView in a pivot item in MainPage.xaml. I was wondering how can I make it work such that all items with objects Event and To-do are at one single pivot item.
I've looked around and found CompositeCollection, but it's only on WPF, not on WinRT yet. I tried dealing with Midgard.CompositeCollection but the data doesn't show up, and I don't understand how can I style these independent kinds of data differently.
Are there any techniques on combining two datasets together on one set of lists but will be styled separately? Is ListView the correct control for dealing with multiple kinds of data, or is there something else?
I'm still quite new to this field; apologies if this is a basic concept I can't quite grasp yet.
Thank you!
There is a way and it is quite simple. Make both Event and To-do inherit from the same base class (could be empty) and create an ObservableCollection of this base type (can also be object if you do not want to create a separate class). Add both Event and To-doobject to this ObservableCollection.
Bind the ListView to this ObservableCollection. Now comes the tricky part. You need to create a DataTemplateSelector. For a compete guide, see http://blog.kulman.sk/using-different-data-templates-with-gridview-in-windows-8-apps/ (this articles is for GridView but it works the same for ListView).
Using Om, it seems like passing relevant parts of the app state to child components is effectively the same thing as not passing any app state but using ref-cursors. What is the use case for ref-cursors over passing pieces of the app state down the chain?
I've read through all three of the tutorials and conceptual overview on the Om github repository but I cant really find an answer to this question. It seems like one could use either one or the other and accomplish the same thing (one either defines a component with (defn blah [_ owner] ...) and uses ref cursors or defines a component with (defn blah [relevent-state owner] ...)
Can someone clarify when I would want to use a ref cursor inside a component as opposed to simply passing part of the app state into that component?
This question is pretty old, but I'll give it a shot.
I believe the main use-case for ref-cursors is to promote modularity and decoupling of the global application state from components. It limits the scope of components to just the data that they depend on, and nothing else.
Normally, you'd pass application state and any change callbacks down the component tree via props, as you say. A consequence is that the component hierarchy becomes tightly coupled with the "shape" of the application state. The components hierarchy will have to match the state 1:1, or else many components will receive big blobs of data and callbacks that only a few subcomponents depend on, which they themselves may never actually use -i.e you might find yourself passing down parts of the global state down the component chain just so that components further down can have access to it. These components are being used as a channel for passing down state, which is not ideal because it exposes them to application state that they have no business knowing about. You run the risk of coupling and lose modularity.
With cursors, component dependencies are explicitly specified by each component upon mounting. The cursors are a black box into the application state -the component itself never has to know where inside the application it is situated. You have the full flexibility of stating a component's dependencies from anywhere in the application state without having to worry about all the transient data being passed around. You get one-way data flow without having to pass update callbacks down arbitrarily deep hierarchies. The end result is excellent component compartmentalization and modularity. As a bonus, you now have a single point into the application state that you can observe for changes!
I used it because when you update it, all of the observers get called.
The project I'm working on is a single page web application developed using MVVM as design pattern.
Aside the first request for the entire page every other transaction is JSON-based, every JSON is binded using Knockout at presentation level.
At the moment we're developing the whole application using a single Knockout-viewModel, every single JSON is being parsed inside the viewModel and binded to the presentation level.
Now, considering how big is the viewModel at the moment I'm wondering if it's a good practice to split the whole thing in different (smaller) viewModels specifically binded to a single element in a page (like it's described in this article), making heavy use of the mapping plugin of Knockout to generate the empty structure (and refresh the datas).
In case this isn't the best practice, how do you suggest to manage the JSON binding? At the moment we're using $.jsonparse() to obtain an object then we push the different datas inside some observable array. But I don't think this is the best way to approach this problem.
Thank you.
I'm a big fan of fanning out complexity across lots of smaller modules, rather than a single monolithic module with all the complexity.
I tend to have multiple view models and communicate between them using the Knockout.Postbox library.
So I'm attempting to use the MVC pattern for a game I'm working on. Everything has been going pretty smoothly so far, but I'm having trouble figuring out how to get my model and my view to talk to each other effectively.
My general model structure involves lots of nested information.
a Level has Rooms
a Room have Layers
a Layer has Objects
Each layer has an index and a corresponding layer in the view that is rendering it. I need the objects to post an update message as they animate so it's corresponding layer in the view can update. I'm trying to use the built in event system to handle these updates.
My issue is I'm not sure how to avoid putting listeners on every object in the game - which strikes me as bad ( perhaps I'm wrong here ). If I change the rooms, the layer doesn't have a way of removing listeners from the objects in the last room because it only accesses layers through the current room. Objects are only updated when they are in the current room, so the other objects won't need to fire events.
The view is set up to cascade events to all of the children, so the root node can receive all updates ( I think I did that part correctly ), and the layer can match the target because it knows which layer it's rendering. The problem is getting the message out from the objects to the view.
Of course this makes sense to me, because I've been working with the code for a while now.
If I can provide more clarification please ask. This is my first time working with the MVC pattern, so I'm sure I could do things better.
If you have any suggestions as to how I might solve this conundrum, please share!
Edit: I have something working keeping track of the current layerset from outside of the view and the model which manages adding/removing the appropriate event listeners and delegating the update event to the layer as suggested. But please, anything I can do to improve this please do.
If you are new to MVC you may want to check out the PureMVC framework for AS3. When I first started learning MVC I started by trying to build my own implementation of the pattern. After trying out PureMVC I got a much better understanding of the structure of MVC.
Your rooms/layers/objects sound like they have a parent/child like relationship and may be a good candidate for the composite design pattern. Basically this is a tree like structure where you could trigger an event which would then cascade through all branches. If you do a search for 'composite pattern' you may get a better explanation of how this may work for you.
There a few solutions you could take, adding event listeners is reasonable, but as mentioned you are going to need to make sure you clean them up appropriately, but this will be a requirement with a lot of other solutions as well.
Another one would be to pass in the layer on object construction, perhaps in the form of a "parent" property. In this case the object would notify its parent whenever it has changed, then on layer update, it would go through and handle all objects who have registered as having changed. This has performance benefits in that the object could change several time between renders, but the parent would only act on this changes once, (when its been told to update itself.) In this case you would still need to make sure you clean up your references properly to avoid garbage collection problems.
Yet another solution would be objects register with them selves as having been changed, typically in the form of a simple Boolean value. In this case the parent (your layer) would loop through all children, presumable stored in some form of collection, and handle updates to all those who say they've been changed. This solution removes the dependencies from object to layer, but in extreme cases, could lead to performance issues, (Extreme case being so many objects the process of checking a single Boolean value on them is too much to handle (that'll be A LOT of objects))
Hope that helps.
Using the Mediator pattern in PureMVC, rather than putting listeners on every object, you could have a Mediator listen to the application instance for the events. Then inside the actual objects, send a bubbling event that bubbles up the display hierarchy to the application where the Mediator hears it. Then the mediator takes the appropriate action such as sending off a notification to trigger a command with some logic, perhaps. The target of the event, would of course be the item in your world that sent the event, so if the Command would need to manipulate or inspect that item, then just pass the event.target in the notification body. QED.
-=Cliff>