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!
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 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.
I am developing an application in Django and I am curious on how I can go about adding a model such that only 1 row is only ever present (i.e. Singleton).
As an example, I'd like to maintain a set of boolean flags of the application i'm running as to whether: it's on or off (so I can manually turn it on or off, perhaps even per module).
I can't see any part of the docs explaining a good way to go about setting this up.
Any suggestions?
Not sure from you explanation in what context you require this but I have a model which holds a number of key/value pairs used in validator checks and other things. The keys are all needed by each implementation of the project but the values will differ between projects. The values should be maintainable by an admin user. The values usually do not need to change very much once set. Given that, I decided to put them in a model. It is a bit weird but simple enough.
You should be able to limit write access to the model to the one row for either your app or your users through your code.
only ever reference the first row in the QuerySet
row = MyVariables.objects.all()[0]
Test if there are rows first. if you think there might accidentally be more than one record then make sure it is ordered (but that should never happen if you did (1) correctly.
There are a couple of apps already dealing with this, check out http://djangopackages.com/grids/g/live-setting/
I'm also a bit confused on your goal, but I'd recommend looking at the Model Instance section of the docs. You should probably look at customizing the validation or cleaning of the model.
If your goal is to only have 1 row flagged in the table for your model: during the validation you can run a query to see if any other row is flagged, and update them to be not flagged. (or delete them).
This question Unique BooleanField value in Django may be helpful.
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.
I need to attach a significant number of additional properties to every user in my Django project. Some of these properties are simple CharFields, others are more complex ManyToManyFields. The trouble for me, is that in my digging around of ways to do this, I've found two options: The user profile method explained in the documentation, and the user subclassing method I see floating around the internet.
They both look complicated, and I'd rather not choose one only to find out that I need to go back and switch everything to the other method after months of development, so I ask here. Which way is the right way?
I have always done it traditional way, which means user profile, because it was suggested in the docs, but this is not the very clearest and elegant solution. You must always handle the possibility of user not having a profile, which I don't like very much. In the next project I would like to use the subclassing and if only it is in stable version of Django, I will press co-workers in my company to try this. This seems much more natural.
If you want to stay safe, use proile. If you prefer to take a little risk and benefit from a much better solution, use subclassing. It was introduced for a reason - there were several talks about weaknesses of profile solution.
The recommended, and, it seems, easiest, is the user profile method.
I've chosen a different path: I had a Clients model, witch should be authenticated. Instead of extending the user model to adjust to my Clients model, I left them separated. And then, when I save a new Client, in the Client save() method I create a user for that client. Then I do the same for updating and deleting to keep them in sync. I tried the other two options, but each had a lot of cons, that's why I gave up on them. And this has been working for me very well.
Regards. Aldo.
Like aldux, I prefer to create a separated Model and let User model untouched.