-
Notifications
You must be signed in to change notification settings - Fork 2
Home
**## Wheel Wiki : Selected questions for our glorious leader (non critical) **
-
I want to have the logged in users name on the tables html page, I see how to do it in python but not in html. return HttpResponse("logged in as %s" % Employee.objects.get(pk=request.COOKIES['uid']))
That's just placeholder code. To get it to the HTML, you would need to create a variable and add it to the context dictionary. And then instead of returning the HttpResponse object as is done there, you'd return render(request, 'template.html', context). or return render(request, 'template.html', {'user_name': Employee.objects.get(pk=request.COOKIES['uid'])})
-
Can you explain what ' context = {} ' is and why is it being passed everywhere.
This is how you get data to the templates. When you use the render() function, the third argument is a dictionary of names mapped to Python identities. i.e. context = {'list_of_stuff': [some, list, in, python]} would make 'list_of_stuff' available as a variable in your template
-
Can you also explain 'request' and why it is in every function call
request is an object that contains info about the HTTP request made by the user that called the view function. There's info about that here: https://docs.djangoproject.com/en/1.7/ref/request-response/
-
For example if you type in 127.0.0.1/waiter/login/ it takes you to the login page, however I cant seem to find the logic of the redirect, they resemble function names sorta buts that’s all I could come up with
Are you talking about the redirect that takes you to 127.0.0.1/waiter if you log in properly? that's in waiter_login(), but it's initiated in login.html via the form submission. The form's action is set to be /waiter/login/, and then in views.py's waiter_login(), I check to see if request.method == 'POST'. When the form is submitted, it's submitted via POST, and that's how we know someone just submitted a form to the page. Then I do the processing there.
-
I need to know how to query if a table exists so I can display it with selectable jquery objects.
You don't need to do this. The better way to do it would be to query a list of all tables that match the waiter in question. i.e., Waiter.objects.get(employee__passkey=[passkey]).tables.all() where [passkey] is queried via the UID from the cookie. i.e. passkey = Employees.objects.get(id=uid) But really, I know you want to learn this stuff, but you don't need to worry about this right now. If you can just get a static HTML/CSS/Jquery page done that even displays a single test table, I can do this backend work that hooks it up and displays actual tables from our database.
-
I have some jquery buttons which I want to redirect to a new html page, how do I do the redirect and I will need to send some info perhaps with it
This is done entirely via JavaScript. $(location).attr('href','/waiter/'); for example, will redirect the browser to /waiter/ on the current domain. You'll need to look at urls.py to see which URL expressions are defined (currently only /, /waiter/, and /waiter/login/ are defined, anything other than that needs to be added and associated with a view function) But again, you can just coordinate this with me.
-
Just curious on how we will implent the table data structure, will it be a module? (this one if probably too in depth for this page will talk about thur)
I'm not sure what you mean. Module? The tables are stored in the database, and they only have two fields: status, and prev_status. Take a look in models.py. An order is associated with a table through the Order model, rather than being stored on the Table model itself. The model just keeps track of its current status and the last one, so it can be reverted to once the current status is completed (i.e., current_status could be NEED REFILL and prev_status could be ORDER PLACED, and once the refill is taken care of, we can easily revert back to ORDER PLACED