simple song CRUD application. In our models.py file inside the “musicapp” application we created, you are expected to add the following Models and Attributes.
Model: Artiste, Song, Lyric Attributes for “Artiste” : first_name, last_name, age Attributes for “Song”: title, date released, likes, artiste_id Attributes for “Lyric”: content, song_id
As you might have guessed, there is a relationship between all three Models. An Artiste can have multiple songs, and a song can have multiple lyrics. A song must only belong to one Artiste and a lyric must only belong to a song.
I am new to django and i am trying out this new task.
Related
We have many "Configuration Entities" in our system. For example: list of banks, list of countries etc. Each list contain up to 100 items all from the same object model.
For example: Bank {account number, bank name, bank description}
We would like to build generic/dynamic editor that will contain:
grid view: a tabular view that show the list of items (add, edit, delete buttons) with pagination, sorting and search.
edit entity view: enable to edit the entity properties (with input validation).
We want to use it to edit all our different "Configuration Entities" with minimum work/boilerplate for adding new entities.
So I was thinking that we need entity descriptor (the entity properties, metadata and validation, rest API metadata, etc.) that will be the input for this module - then the module will be built dynamically.
Is there any already exists open source that I can use (in Vue or React) or should I build it from scratch?
I need an advice for my application. I have fleet with Vehicles and every vehicle has its owner. I would like to have possibility to add "Items" to these vehicles such as Insurance etc.
http://s27.postimg.org/c4hb8o02r/screens.jpg
I would like to click on the icon and have a list of items for this vehicle.
Should I create a methods for this within Vehicles Controller or create another one?
The "Items" are different database entities than the Vehicles. You will probably end up doing other actions with those "Items" in the future beyond viewing them (e.g. Create/Edit/Update).
You'll want to manage different database entities separately in an MVC framework.
So yes, create an ItemsController. You can then code a "getItemsByVehicleId" method and build out the View to display them.
So I got the tables you can see in the image below:
.
What I would like to do is to create a relationship so that each user (of django auth_user) will be enrolled(or able to enrol) to exactly one "course" so that he will be able to see next events for his modules.
Do I have to create another table and place 2 foreign keys or this is a way to do it in 'php' and it's more simple with Django? I was suggested to create 'student' model inheriting from 'User' with extended behavior and one to many relationship on auth. I tried to do that but unfortunately had not results since I'm really new to Django & Python.
If every auth_user (or auth.User) will be or have the opportunity to be enrolled on a course I would create a 'user profile' model that has a 1-to-1 relationship with the django User model. You can store additional User data in this model, including what course they are enrolled on. See https://docs.djangoproject.com/en/dev/topics/auth/customizing/#extending-the-existing-user-model for more details but here is an example:
class UserProfile(models.Model):
user = models.OneToOneField('auth.User')
course = models.ForeignKey('courseapp.Course', null=True)
You would probably need to create a signal that gets fired each time an auth.User object is saved, such that if it is the first time that User object has been saved, it automatically creates the UserProfile:
from django.contrib.auth.models import User
from django.db.models.signals import post_save
from yourusersapp.models import UserProfile
def create_user_profile(sender, instance, created, **kwargs):
# Automatically creates a UserProfile on User creation.
if created:
UserProfile.objects.create(user=instance)
post_save.connect(create_user_profile, sender=User)
When you query a User object, you can then reference the User object's profile like:
user_object.userprofile
You could then create a Course object and link the user_object indirectly via its UserProfile to that Course:
course = Course.objects.create(name='course_name', next_field='whatever')
user_profile = user_object.userprofile
userprofile.course = course
userprofile.save()
Now you have a user object with a UserProfile that is linked to only 1 course. Many users can be on the same course, but a user can only be on 1 course. You can also reference all users on a particular course like:
course = Course.objects.get(name='course_name')
course_users = course.userprofile_set.all()
HTH
I think that you can go about this one of two ways.
Extend the User model. 'Student' would probably be a good name for your new model. It would have a OneToOne relationship with 'User', and a ForeignKey relationship with 'Course'. It can store any other information that is applicable to students only. Documentation for how to do that can be found here https://docs.djangoproject.com/en/1.6/topics/auth/customizing/#extending-the-existing-user-model
Create a custom User model that has a ForeignKey relationship with Course. This approach is a bit more complicated, but yields a slightly cleaner end result. Documentation for that is here. https://docs.djangoproject.com/en/1.6/topics/auth/customizing/#substituting-a-custom-user-model
Sorry if it seems like I'm just sending you to the Django docs, but both of those sections are well written and should explain things pretty clearly. If you'd like to post another question with example code we can try and see why your original attempt at extending the User model didn't work. By the way, your "Student" model shouldn't have to inherit from the User model in order to extend it.
I'm building a site for a summer camp using Drupal 7, and I'd like for it to allow parents to register their kid(s) for week(s) at camp and then pay for it.
Creating an "event" for purchase in Ubercart, and using the pay per node module is the best way i can find to make this happen, a la the great tutorial series done by Pete Yaworski. Unfortunately, this means that parents have to fill out the fields for each week of camp purchased for each kid making this a multi-step process as many parents have 2 or more kids that they register for 2 or more weeks of camp.
I tried thinking about this in in terms of the Organic Groups and Profile 2 modules, where parents can create "kids" as nodes or sub-users, and I also tried the Field Attributes module to incorporate fields as product options, but I failed to come up with any useful implementation.
I think the best option is to allow Parents enter information about their kids (ie. name, age), possibly by entering each kid as a node. Ultimately, I'd like them to be able to purchase individual camp weeks and check a checkbox to indicate which kids are associated with each week, and have it all go into one cart for one purchase.
I'm just brainstorming at this point because I've just hit upon a lot of dead ends. Thanks for your help!
Well, it's been a while and i thought i might share what i've learned. Just to note, i switched to Drupal Commerce, which i think is much better equipped to handle this type of business.
The site is more focused on one user registering multiple people (kids) for multiple events, so having to fill out a registration form for each person specifically for each event that person is being registered for is a bit annoying, and bad UX. Instead, i allow registered users to complete a form (name, address, contact, etc..). Upon completion of the form, they are given a new user role via Rules which allow them to create content of type "kid". This is really sort of an extra step for the specific summer camp site; we expect the kids to have the same address/phone/etc.. as their parents. The parents can create "kid" nodes filling in field like "allergies" "health concerns" "age" and "name". These nodes are passed through a View with a Contextual Filter based on the User viewing the View; the View shows only content created by the User, and only shows field "name". This is then given as an entity reference to a Line Item Type using a checkbox/radio widget. Events can then be created as Products and given that Line Item Type. When a User is viewing the products he/she will see the "Name"s of the "Kids" they have created as choice next to the "add to cart" button. Conveniently, everything in Drupal Commerce from Products to Orders can be interpreted though views, so as long as the "kid" is attached as a line item, it's easy to organize the info about who registered who for what event when, and retrieve further details about all of that.
So, Parents are able to register with the site, fill out basic information, enter in information for each kid they want to register, then select which kid they want to register for which event. More useful, on the backend, the admin can see which kids are registered for which event, as well as who their parents are, how to contact them, and any important info specific to that kid.
Hope this helps anyone doing a similar project. :-)
In my app, user can create vehicles. On the "show specific vehicle" page, I have an instance of Vehicle (which extend RelationalModel from Backbone Relational). When I change the avatar of the vehicle, this model is changed.
In another page "show vehicles list" of the application, I have a gallery showing the vehicles of the user. The models (instances of Vehicle too) are in a collection. Unfortunately, they have a different CID and thus are not updated properly when the user changes the avatar of the Vehicle in the show Page.
How to deal with that? I would like the Vehicle #9 to be the same everywhere.
I would define an application-level vehicleCollection (A) where you store all vehicles you get from every single request that returns vehicles (B, C). Since every vehicleId will be the same, you can do a look-up in the main collection (A) if the model already exists when you loop over the resultset from the other collection fetch (B, C).
You will most likely need to work with temporary collections and inject the relevant model from the main collection (A)
If you look through the tests that come with the Backbone package (or just go to their github repo) you can clearly see how it works adding the same model to different collections