I had problem with saving relation to object with same class as parent.
You can check this problem here.
When I read that I can easily set the relationship after the promise has fulfilled here I created another example with that info in mind. But it doesn't work as I expect.
What I expect
Create array of Box instances with relation to previous Box instance in each.
And the question is if I'm doing something wrong or it's a bug. Let me know if you need any informations.
Your example isn't clear and simple enough. It needs to be isolated to EXACTLY what you're having an issue about and nothing else.
Having said that, I have had quite a bit of success saving relations to objects with the same class as parent, and so I don't think this is a problem with Ember Data or Ember.
Your code is quite convoluted and uses the sync library, which I'm not faimilar with.
It's a good idea to things as simply as possible at first, so try creating a jsbin with just the isolated functionality relating to saving relations that you're attempting, and then adding additional layers of functionality and testing after each add.
Related
I am designing a master/detail solution for my app. I have searched for ever in the django docs, also here and elsewhere I could, so I guess the answer is not that obvious, despite being an answer many people look for - not only in django, but in every language, I think.
Generally, in most cases, the master already exists: for example, the Django Docs illustrate the Book example, where we already have an Author and we want to add several Books for that Author.
In my case, the parent is not yet present on the database think of a purchase order, for instance.
I have thought to divide the process in two steps: the user would start to fill in the info for the master model (regular form) and then proceed to another view to add the lines (inline formset). But I don't think this is the best process at all - there are a lot of possible flaws in it.
I also thought about creating a temporary parent object in a different table and only having a definitive master when the children are finally created. But it still doesn't look clean.
Because of that, for my app it would be ideal to create the master object at the same time as the detail objects (lines) - again, like an order.
Is there a way where I can have the same view to manage both master and detail? Like this I would receive both in the same POST request and it would make a lot more sense, not to say it would be much cleaner.
Sorry if it's too long, and thank you in advance!
So I found out that in my case the process could actually be split in two phases.
For this I simply use the traditional model form and inline formset.
But! I also found out that there could be several answers to this:
We could get crazy and build some spaceship in AJAX that would get the job done, simply by sending a JSON object (in which the lines could be an array of objects)
Django also has its ways and it's possible to send multiple forms in the same request! (thank you #mousetail for the tip).
Of course, be there as it may, there are many ways to build a house, these are just the ones I found out.
I'd like to augment events/occurrences in django-scheduler with three things:
Location
Invitees
RSVPs
For Location, my initial thought was to subclass Event and add Location as a foreign key to a Location class, but my assumption is that each occurrence saved won't then include Location, so if the location changes for one occurrence, I'll have nowhere to store that information.
In this situation, is it recommended to create an EventRelation instead? Will I then be able to specify a different Location for one occurrence in a series? The EventRelation solution seems untidy to me, I'd prefer to keep models in classes for clarity and simplicity.
I think Invitees is the same problem, so presumably I should use a similar solution?
For RSVPs, I intend to make an RSVP class with Occurrence as a foreign key, and as far as I can tell that should work without any issues as long as I save the occurrence before attaching it to an RSVP?
I've read all the docs, all the GitHub issues, various StackOverflow threads, the tests, the model source, etc, but it's still unclear what the "right" way to do it is.
I found a PR which introduces abstract models: https://github.com/llazzaro/django-scheduler/pull/389 which looks like exactly what I want, but I'm reluctant to use code which was seemingly abandoned 18 months ago as I won't get the benefit of future improvements.
EDIT: I'm now thinking that another way to do this would be to have just one object linked to the event using EventRelation, so I'd have an "EventDetails" object connected to the Event via EventRelation, then include FKs to Location, Guests, etc from that object.
I should then also be able to subclass my EventDetails object with different kinds of events and attach those too. I'll give it a go ant see if it works!
Just in case anyone find this and is wondering the same thing: I ended up ditching Django-scheduler and using Django-recurrence instead. Had to do a bit more work myself, but it was easier to create the custom event types that I was looking for. Worked pretty well!
I passed the result of this.store.findAll('something') to a component so I could create a dropdown control. Everything works great but I'd like to find the object I selected by reading this property.
Everything I read says its bad practice to inject the store into these components and since I already have the data in the property I thought it would be easy to read. However it's in an Ember model array that doesn't seem to be so easy to open because the array is deep down the stack.
I started heading down something like this.get('myprop').content... but I wondered if this was the correct way to do this. It seems I should be able to open them as the model they should be.
Any suggestions would be helpful.
it turns out the best way I could find to select my model was the 'peek' function. Not exactly what I wanted to do but it works.
Some of the comments below my initial question also work, but nobody ever actually added an answer so this is my answer. :-)
I am trying to implement a ProxyModel that takes a source Model that represents a flat, table like structure.
Then you can select one column of this model as a grouping value.
The proxy model should then create as many top nodes as there are distinct values of this column and sort the underlying rows into them.
But when doing this, is subclassing QAbstractProxyModel a viable option?
Since mapToSource(const QModelIndex& proxyIndex) will not always return a valid source index for a valid proxy index.
Does someone have a better solution, perhaps just using a QAbstractItemModel without the built in proxy functionality?
Here are two example projects which address this issue, for anyone's future reference. (One of them is mine, I do not mean to spam, it just seems relevant.)
GroupedItemsProxyModel (doc)
QGroupingProxyModel (doc)
Edit (response to comment): Both projects implement what, I believe, the question is asking about. I think examining the source provides the best examples and would obviously be too long to paste it all here. I've provided links directly to the source and to relevant documentation.
UPDATE: Sorry, understood this a little wrong. I never derived from abstract proxy model so I am not sure about that. However I would start using a QSortFilterProxyModel. It may happen that it has some functionality you do not need but this does not hurt. On the other hand implementing your on proxy model could hurt since it requires additional work and know-how.
If you should experience problems switching from the non-grouped structure to the grouped structure within the proxy model consider switching the model of the view (one showing grouped data, one showing original un-grouped data).
I have a C++ application designed according to a classic Model-View-Controller pattern. The model is modified through a controller interface by an external source by means of a Command pattern. The commands are represented by an Action object (and its derivatives).
Now I want to be able to undo the modifications, but my problem is that I have no getters in my controller, only setters. This seems quite logical, since there's no reason someone should be able to get info about the model through the controller. Thus, I can't have my Action objects store the state of the Model, since they have no access to it.
How would one solve this? I'd like to keep my application as extendable as possible and I'm not quite sure which option is the best for that. The methods I though up so far are:
Putting getter methods in the controller. This seems to go against the MVC pattern.
Giving the Action a pointer to a View. The Action could then either:
Use individual getters to get the state of specific elements of the model to be modified.
Use a Memento method implemented by the Viewer.
Maybe there's an even better way to do this? Right now, to be the best option seems to be 2, suboption 1 (with suboption 2, I'd quite possible store a lot more state than necessary to undo one action).
Note: I know there's other questions on how to implement an undo action. However, the only answers I found gave suggestions to use a Command or Memento pattern. I know this is most probably the way to go. What I'm asking for is how to integrate this as cleanly & extendable as possible in an MVC design.
[Edit] What I don't like about the Memento pattern is that it forces me to store a complete state. Let's say my model is a 1000x1000 matrix and my Command is ChangeOneValueAtLocation. To be able to undo its changes, the ChangeOneValueAtLocation object only needs to store the previous value of the location it's changing, but that doesn't seem possible with Memento. The larger my model, the biggest this problem becomes.
[Edit 2] Another problem I have with Memento in the specific case of this application: for every method a Command object can execute on the Model, there's a method that does exact opposite (or can easily be coaxed to do so). This is why I would find it a waste to have to store the whole state, there should be no need to, reverting a single Command is very straightforward, the only problem is getting the data to be able to do it.
Also, I don't need to be able to undo a specific Command, only the topmost one on my history stack.
I also support the model layer containing undo support. There are quite a few ways to handle this in the model side. The first and most obvious is the models themselves remembering the history of the changes with "labels", but this is probably going to be difficult to synchronize for all your model classes.
One other option is to create a history manager that has a concept of a "transaction", which causes it to generate an undo point, and take a snapshot of your models, or start recording changes (for reduced memory usage), or record commands that cause model changes, etc.The models notify the manager on change, and finally you complete the transaction (or not, because the next start of transaction can be the end of the previous one). Once you add in the ability to rollback to a certain point, the work will be done. By making things slightly more complicated in this manager class, you can create an undo tree (like the one in emacs), so it is also quite a flexible way to approach it.
The above solution is not quite in the model layer, though. It is a support class that is driven by both the model and the controller. If you remove the transaction concept, then it is completely model-driven, but implementing the concept of an undo operation might be somewhat tricky. If you change it to act as a command proxy, it is the only entity used by your controllers, and is clearly a model. It is too rough a design at this point to choose one approach over another, but I am leaning towards the "transaction" model. It feels easy enough to implement.
I'd really recommend building the undo tree into your Controller
Building it into the model could run you into trouble:
the 'model' is usually fragmented per view (each view has it's own partial model)
this will lead to non-atomic undo (undoing part of an operation due to the view not knowing what other things (models) would have to be undone etc)
The controller is the 'action dispatcher', so it'd have to say
clone state (all models) snapshot
add action to history with reference to snapshot
run action
then undo would be
pop action off history stack (optionally push to 'future' stack)
restore snapshot
display view
Also, make undo work with highlevel actions (see Composite Pattern or Command Pattern)
Build the undo functionality in your model itself. Let you model keep a list of commands. Run the commands in the reverse order when your view passes an undo signal to the model.