From Database to Webpage - Day 2 - Django Bootcamp

hey everyone that looks funny welcome to day two of the django boot camp this of course is our agenda this is gonna be our pretty standard agenda throughout the entire boot camp we're gonna talk a little bit about the overview of what we're covering why it's important just a little bit and then we'll jump into the code and then of course some live q a um yesterday was a lot of fun i am really enjoying this format um hopefully you guys are enjoying it too please let me know in the comments if you are the coolest thing about this as well is if you miss it live you can always watch it later or we re-watch it at other times the thing i'm really trying to do different with these boot camps is this overview portion of it of course the live q a towards the end to clarify any questions you may have but since i've been teaching django so much i really hope that i kind of lay it out pretty much all on the line where you don't have that many questions about that particular day hopefully that's the case but of course you will always have questions so be sure to stick around for that live q a towards the end of this and my plan is to do this for about an hour maybe a little bit less than that it really depends on how many questions we're getting that are relevant to this day so i'm not really going to be covering questions that are just general like my live q a questions so who's ready to get started now in general this is what we talked about last time right so you're like jon snow you know nothing i'm assuming that of course you are not like jon snow you're probably much further along than that probably know some python now if you're confused about any of those things go back to day one or day zero and start all over but the general idea is this we when we go to a web page we're requesting a specific url that goes to a server and on the server we learned last time that django models is how we actually interact with our database and of course this database can be sqlite postgresql mysql those are like the major ones by default supported by django there are other ones that you can use in django but those are the default ones so that's what we covered last time and well it's really just about that interaction what we see there django's sort of playing a middleman role between the request and the database so what we want to talk about this time is how to actually take that data and put it on a web page like we got this request coming in and how do we actually bring it in into a web page now before we actually look at any of the code related to this what we need to understand is how urls work or really how you know every single web page essentially works so let's break down what a url is and just so we have a gist of how these things are going to be unpacked later using django so this is true for every kind of website every kind of web application so what we've got here is a protocol so a protocol is really just a way for your web browser to connect to it it's in our case it's either going to be secure or not so http or hbs you probably are very aware of this sub domains probably not that big of a deal either www is the most common sub domain there is and it is the root sub domain typically we've got a domain name top level domain hopefully those things are like pretty well understand by most of you at this point right i don't think i need to go into too much depth here the second half of this where it's concerned with django is also concerned for us right so that's the path the query and the query parameters we don't really need to worry about the fragment other web applications absolutely use the fragment and use it to great effect but in our case we're really concerned about the path the query and more specifically the query parameters so this path part can be well it can be really long it doesn't have to be just one word like we have here so pretty much anything in between slashes is a path all the way up until you see something like a question mark and that question mark denotes that there's additional parameters that are being passed to this url so really the question is how do we actually handle any given url and what is it that we do to make this possible in django this is handled in every kind of web location django just handles it its own way which of course that's what we're going to be covering here today so all of this kind of builds up to handling django view so a url comes in django handles that url routes it to a django view and then that view returns back well it returns back potentially html css and javascript but in our case we're going to be returning back really really simple data but it is going to return something back right that's what it always does it takes in a request and it returns a response now we're going to talk about the request response cycle later what our main concern here is just really handling any given url and displaying a some sort of data based off of a database entry something that's actually inside of your model and all of that is thanks to django views so let's go ahead and code so jumping over into this of course we are still using django version 1 or 3.1.2 definitely not django one um and we're gonna be using vs code as our primary workspace uh and code editor okay so um again i'm picking up from day one so if you don't have day one stuff done you're gonna be incredibly lost unless you just want a conceptual overview which in that case you will not be lost so if you remember back when we actually created these apps views.pi was also created for you and it doesn't actually matter whenever you're creating these apps as long as you're running python manage.py start app and then the app name you will always get your views in there that's a default feature that jango's had i think since django 1.3 probably maybe 1.4 which is like 10 years ago so this is likely not going to change now one of the biggest changes to 3.1 i'll just say this for those of you who are really concerned about the newest stuff is the ability to do asynchronous views we are not going to be doing that we're going to be doing synchronous views here so what is a view it's itself well a view just takes in any given request so if we're on a web page it takes in that request and it actually returns that response right so going back into this right here we let's look at this interaction a little bit more we got a url coming through that url goes into the server the server handles it with that view and then it actually renders something out so that means that our view itself needs to handle that so we'll take a look at function based views first and i'm just going to call this home view and we're going to talk about what needs to happen here so as with many python functions it's well you just declare a function define function name i'm arbitrarily calling this home view but you can call it whatever you'd like just make sure that you're kind of following somewhat standard practice i'll talk about those standard practices in just a little bit but the main idea here is the actual view itself can be a function but it can also be a class okay so um these are two different kinds of ways to render out content so let's actually see how we render our content now i'm actually not going to be using the shortcut method for render we will definitely use it eventually but not just yet so i'm gonna go ahead and do from django.http import http response so when you actually make your request to any web page especially if it's managed by django it needs to return actual html so it actually needs to have an html response of some kind so that means that my view function when i go to a url and i have it mapped up to this view we'll do that it needs to actually return a html string of some kind so html string can be really simple it can be something like h1 hello world now if you know html you just know that whenever you open an html tag you need to close it of course there's exceptions to that but just to generally open close your html now this is the entire html that's actually been sent and also if you know html you know that that's not really valid html we need a lot more to this now that part we're actually going to be covering when we cover django templates and that's going to be in day three but for now this is fine we actually have the ability to return some sort of response to our server so we've got this view function here how do we actually use it how do i actually return this data well one of the things that i also want to do here is pass in the argument of request and i'll also pass in args and keyword args okay so request itself is built into django we'll look at this a lot more in depth as we go forward but for now just keep in mind that it's just requests we'll just be looking at this view in a very simple fashion right now okay so how do we actually use this view that's the next big question well first let's go ahead and activate our virtual environment so um it's source bin activate or if you're on uh windows you're going to do scripts flash activate as we mentioned before and now i'm just going to go ahead and do python manage.py run server okay so i'll go ahead and open up that development server i actually already still have it open up from yesterday but here we go so by default django handles the root url so the root url or the index page is with none of those paths so what i showed you here that is the index url or the root url there might be a trailing slash there or not but as soon as we actually add in some paths here like this one we are going to be drastically changing what we're requesting and of course if i actually did slash search here it gives me this page not found 4 4 error this is actually a really great thing to see because django's showing us that hey django is aware of this url i don't need to do anything extra to make sure that django knows hey just say this is a page not found that's really nice that's one of those batteries included sort of things that we don't have to declare that hey this this url is a page not found which i think is awesome okay so let's go ahead and actually wrap this in let's do it on that search url so inside of our django configuration folder remember where settings.pi is where urls that pi is we're going to jump into urls i'm going to go ahead and import this view and as we see here these url patterns are already there we already have some url patterns we'll unpack this a little bit more in the future but for now we're going to bring in that view that i just created in the products app so make sure you save it of course and we'll just go ahead and do from products import views okay and now i'm going to go ahead and create a path that we want to handle so in my case that path we're going to go ahead and call it search i will have a trailing slash there and now i'll go ahead and do views dot home view now vs code gave me that nice completion there but this is actually how we can render out that view now this is actually not the method i prefer importing these views but you'll see this a lot and we'll talk about how to import it later in just a moment but of course this is from the actual app name right nobody no no big surprise there and this is the view module and inside of that view module is our actual view which is incredibly simple so now that we save this and we refresh this url what do we get hello world wow no shock there right that is incredibly simple but now if we go to the home page now we get another page not found right so the index page is no longer found now the reason for this is because we just modified these url patterns if we comment that out save it and refresh in here django will know hey you really haven't modified any urls so let's just render out that default page but as soon as you modify them then it actually does change what we want to see cool so now the next thing about this is well why do i have only one single thing happening in this view right this is not a dynamic view at all so how do we actually turn this in to a dynamic view in other words how do i actually show you how to get data out of our database well first and foremost let's actually make sure that our database has data right so i'm going to be pulling from the products app itself and the products model or the product model itself i have two objects in here so here's one and there's two right so i do actually have the ability to grab something that's stored in the database so this is the one i'll grab and i'm actually going to grab it by the id field that is automatically created and that id field is very clear when we actually are using the django admin but even if it's not clear we'll actually take a look at that in the python managed django shell so i'll go ahead and create another terminal window here and again i'll do source bin slash activate and we'll just run python manage.py shell now the nice thing about vs code is you can have two of these terminals running at the same time makes it incredibly easy so let's actually see what it is that i'm trying to do here i want to render out one of those products or both of those products based off of the view that i'm using so i want to make this quite a bit more dynamic because right now it's really static it's only rendering out this one single string it's not really that cool it's not really that impressive i mean it is cool for sure but it's not that impressive yet so let's go ahead and jump into this shell here and i want to remind you how to actually import data from the database into django so go ahead and do from products.models import product now if you remember that's the actual class that we were using that allows django to manage the data that's in the database so here we go we've got that imported now what we can do is we can say obj this is fairly arbitrary calling it obj also object that's very typical in django projects as it will be called obj sometimes it'll be called instance as in you know instance so we'll go ahead and just go ahead and say obj equals to product dot objects that get and we'll give it an id in here and we'll say id equals to one okay so we got obj in here there's that first product now i can also use something called a query set which is often denoted as qs which query set is also what it'll be denoted as so qs equals to product dot objects dot all so query set is actually a list of these objects right so if i type out qs i see that i have each object or instance of that model class that's stored in the database with this query so that also means that i can iterate through it so for i or for obj in qs i can actually print out obj.id remember it's that hidden field that's in every django model by default we hit enter and there we go we have two different object ids in here okay so again that's a really quick and easy way to grab some data from the database so let's actually go back into our view and we're going to go ahead and say define product detail view and it's going to take in a request and i'll give it args and keyword args and then we're gonna return http response again of something so of course i need to actually import things very similarly as i did down here so i could do from products.model's import product but i am inside of that product app already so i actually don't need to do that i can do a relative import so i'll just do from dot models import product and now in this detail view i'm going to go ahead and say obj equals to product dot objects dot get id equals to one right so i know that that exists in the database based off of this query um so now i'll go ahead and say uh we're gonna return back a string substitution and i'll just go ahead and say object or rather product id and that's going to be equal to obj.id okay so now that we've got that let's go ahead and grab this we're gonna use that view now or that function inside of our paths so i'll go ahead and say path and we'll go ahead and just do products one and then product detail view and that is in views dot product detail view so now that we've got that let's go ahead and take a look at this new path now why is it that i named it this way well this will be very clear in just a moment but do note that i have these slashes here you can you can actually get rid of those trailing slashes if you like there's other configuration for that i don't think it's relevant yet um but the idea is yeah this is the products app so it makes sense that i'm gonna name it in these url patterns so let's go ahead and actually take a look at that product so we come in here and it's products one we hit enter and it looks like i have a failure let's go ahead and take a look at the server let's see why i've got an invalid syntax error um so it's telling me exactly where this error is it's on line 24 in urls.hi so we go into you know we can actually hit control click to open that page and the line itself so line 24 is right here and what we see is i missed a comma here really simple error but probably pretty frustrating if you don't know how to diagnose this error okay cool so going back in here notice that it refreshed on its own and sure enough there it is product id one okay so we just solved the problem even though it doesn't feel like it we just solved the problem of two things one is how do we handle any given url so going back to our slideshow here slideshow how do we handle one of these paths right or one with multiple like slashes in it essentially so we did that that was all driven through urls.pi and we also did the other interaction where we were able to grab data from the model and render it out to html and css so the next big question would be well how do i build this out to be a lot more complete well that's where django templates come in that's one of the other powerful things about django by default but i will say there's something else that you can do especially if you're building a rest api i can actually say product api detail view and instead of http response i can use a json response and of course that's javascript object notation and with that i can actually come in here and pass in a dictionary now and say id equals to obj.id and then we grab this one bring it over into our urls and add one more path here and say api products one and back into our view here we'll just grab an api detail view and if we take a look and come in here and now say api products one we hit enter and now it's actually a json object it's in json object notation so if you're using something like react or view or any sort of javascript front-end or even ios or android all of those things can now be handled by that data and that's incredibly simple i think right so it's just it's just a slightly different response type um and it's really only to get the data it's not actually about updating the data but those are function based views but we're actually missing one critical element and that is how do we actually make this arbitrary right so this right here so that is also incredibly important how do we make that a dynamic lookup well it actually comes in with the urls but before we go much further i will say there are other frameworks out there that actually declare the url here so something like this now there is sometimes a really nice way to just say oh wow that is actually amazing because now i can say oh these are my url patterns and it's not that incredibly confusing because this function matches this url now for smaller projects that is actually really really nice for bigger projects actually seeing the mapped out url patterns like this is also incredibly nice so this is one of those trade-offs that i think django does really well by separating out these urls from the views themselves so you're really just focusing on what the view is now i realize for some of you that's probably a little bit outside what we need to know right now but i will say that if you're looking for something simple like this and only simple like this flask and fast api are really good at just these basic simple things and it doesn't necessarily have the batteries included but that's where those things really shine in case you were wondering okay so i do want to say that there is a another piece of this is adding in those dynamic urls so coming back into how these paths work we want to adjust them just a little bit so i'm going to go ahead and copy and paste the first one this same concept can be applied to the api version or the json version and i'm not actually going to cover that part itself but in here you can actually pass in a path and you can add in an arbitrary argument and say what it is so we've got an id here this is going to be our keyword argument and it's going to be of type it so an actual integer has to be in there for this path to be considered a match so if we go back and go into products one uh oh we have an error this is good so this is something also also that i really really like about django is it will raise these errors right off the bat right so what we see here is i'm using an actual invalid path lookup so it should actually be in colon id and that will that should actually solve our actual product routing problem right and i think as a beginner you will actually make the trip up on this mistake fairly often um but i do want to cover one more dynamic url lookup in a moment called regular expressions but this is just a very simple way to do an integer type lookup so this is an object type so you know if you said something like int one um that would actually give you an integer of one right versus scr of one that won't give you an integer of one right it'll give you a string of one or actually using that integer and so that's just generally speaking how that actually works so now that we save that we can refresh in that product nothing changed in this case but if i actually go to a different product id here so in the url i actually want a different id well still nothing changes so now the question is how do we actually handle what that parameter is so this parameter is actually being passed into the view itself so the view itself is right here and we had this args and keyword arcs here if i actually get rid of that and only pass in the request and refresh in here now i get this this argument this unexpected keyword argument of id now this is a python error right this is not a django specific error if you pass in arguments that aren't being handled in any function it's going to say hey i don't know about this argument in this in much like this so what we need to do is actually pass in what that argument is in this case i use the argument variable name of id right so i can actually pass an id in here now and if i refresh in here now i get product id of two so now it's actually a dynamic url i mean it's really just that simple to me that's incredibly simple now if you've never done any of these things maybe it's like outside the realm of what should be considered simple but actually doing this with raw html and css i'm not even sure if it's possible maybe if you use some technology like nginx you could probably figure it out but this actually makes the dynamic lookups into our database incredibly easy right it makes this whole process like just absolutely painless well that's what i think hopefully you feel that way now too with this um hopefully clarified a little bit more but i did say that there's a couple other things i wanted to cover okay so let's go back to it first off is what if we actually go to a product that does not exist this is an exception that django runs so django itself is saying hey this product does not exist this is called a 500 error on your server so in production you don't want to have these things happen when we're testing it's fine this is actually kind of expected to happen because we actually don't have a product with the id of three yet we only have two products so yeah this one doesn't exist so what we want to do is much like if we go to a url that actually hasn't been handled yet we want to raise what's called a 404 error as in a page not found error now there's many different ways on how to do this i'm actually just going to show you the simplest way which is actually handling exceptions so what we can do here is say try obj equals to that product and then we can say accept and in this case we use the model name product dot does not exist and then we can raise something called an http 404 error which is something we just need to use right here okay so 404 error we just import it from http this is a very very common way to handle whether or not a product exists now how do i know that it does not exist in this format well i'll show you again let's go ahead and copy that same lookup i realize this is probably not efficient but let's go ahead and copy that same lookup go back in here and if we refresh we see that it literally says does not exist so that's actually the exception so if you actually search django does not exist you'll get the response of you know exceptions you'll also get some really good stack overflow things trust me i do this literally all the time even for things that i probably should know i'm constantly doing this so it's totally okay for you to do this and not necessarily memorize every little thing the the just the general idea is if we have some errors we need to handle them somehow you know when in doubt you can also say something like this now this is for you beginners if you're more advanced you're going to understand that you probably shouldn't do this in the long run but in the short run it's totally okay literally just handling the exception in this way because your user you don't necessarily want them to see those server errors pretty much never right or as little as possible unless it actually is a drastic server error but this is a lookup error this is a lookup problem and if the id doesn't exist or if there's something wrong with the model itself then it's just going to raise this 404 error and that is not really that bad but when we want to get a little bit more advanced when we want to actually handle specific errors that's when we use something like does not exist because that's actually the proper error here that we should render out so going back into our products three here we refresh now we get this page not found take note that it doesn't actually show me anything else besides the page not found in other words if i actually went to another page that's not currently being handled django now is saying to me as the developer hey we don't know about this page we looked in all of these urls we didn't find a match anywhere right so those url patterns are looking for a match to whatever this path is we definitely need to break those urls down a lot more so not to worry that will come later in the boot camp but for now just know that when we run that you know page not found or the 404 error it actually just gives us this which is the proper error that we want to see when a product or some sort of dynamic lookup into the database is not found so it's a really simple way to handle it the next question might be like well how do i actually handle it in the json response it's not going to be http 404 because this right here is actually rendering this will render an html page with a status code as well so with a http status code of 404 now this this is definitely getting more towards like the complex area of web development but the reason i'm mentioning it is for those of you who might have familiarity with other web frameworks or other html type things so how do we actually do this in the json response type view well we can just copy this the same thing and or actually sorry i don't need to copy that i need to copy this same thing here i'm down here and i'll get rid of this lookup because it's in the try block now and instead of raising the http 404 we can actually return a json response and give a message of something like not found with a status code of 404 okay so this time it's going to return it will return json with an http status code slightly different but it's just one of those things that you actually need to declare itself notice that i passed a dictionary in in the first spot and then i added the argument of status code which is really really cool so let's try this again with api products and three i'm getting a page not found okay so i actually need to make my urls dynamic for that as well so yet again i can actually come in here and paste this in here but for those of you who want to be a little bit more advanced we can also look at a regular expression called repath in older versions of django it was just called url re path is for a regular expression itself so to do this we can just pass in a matching pattern in here for id and this one is going to be slash d plus okay so there is a regular expression to match for that specific argument again if you don't know regular expressions i recommend you should check them out but if you don't you can absolutely use the built-in method this is actually one of those newer things that django has that is really cool because it simplifies the process of things like id lookups or integer lookups so anyways we refresh in here and we get a built-in function id oh yes okay so um field isd but expected a number but got a built-in function itself looks like i have an error in the regular expression that i'm not gonna spend time diagnosing right now sorry about that for those of you who are clamoring for those regular expressions this is what happens when you record things live okay so i'll just go ahead and use the built-in path method and not diagnose that error right now ah so it actually isn't related to the function or is it let's take a look so back into our view ah yes it is not that is good that is good i am glad that it was not actually related to the path itself um okay so this was a silly error something that i probably should have flushed out a lot more prior to doing this and showing you guys so my apologies there but it is good to see how i diagnose errors when they have it so going back to this regular expression itself let's refresh in here and i get this field id expected number but got this so we got a type error here so python actually has a built-in function called id so i'm actually what i'm going to do here is bring this out of this try block and instead put it here and refresh still having that error so what i'm also going to do then is actually get rid of args and keyword args save it refresh again and yet again i'm getting that same error that we had before so it's an unexpected keyword argument of id so that also means that in here i need to actually pass in id as an argument and that is the problem uh so thanks for bearing with me on that we'll save there and we'll refresh and now i get this unexpected keyword argument of status code so this is really important for you to see all of these errors this stuff happens all of the time it happens to me all the time whether or not i'm prepared for it right so django json response status code okay so i actually know what the argument should be but if we search in status code we've got http response of status code and then we go back down to the json response itself we should be coming in here and seeing actually status code should be the argument that is peculiar yet another thing i'll have to come back to so it should be status code but we'll leave it in as that silly mistakes but anyways there is our message here so not found i definitely promise you guys i will solve that error uh in the future it's just you know one of those things that i should have uh flushed out a lot more prior to jumping into it but of course this is a little bit more advanced anyway if you need to use json itself okay so now we've got it covered where we can do a dynamic lookup we can change our urls in two different ways based off of the built-in path method based off of a regular expression and then always with those urls we actually want to parse out uh what's coming in and what's being passed so part of the reason that i used id was because it's the same thing that we actually declared in our model this is actually not preferred because of that built-in id function method that we saw earlier so what you actually want to use is pk as in primary key this is actually what's a lot more common for doing these lookups because the id field itself is the primary key in the database so we can actually adjust all of those id fields to being just the primary key and that is actually how it works for best practices in general so we're just going to change all of those to pk and now we're back in here and everything should work as expected or at least i think it should uh because you know unforeseen live errors okay cool so um yeah that is how we do all of those things if you have questions please let me know in just a moment because we will be answering those questions but i do want to recap everything that we need to do when it comes to getting things into a database and then rendering it out with some html or some json so first and foremost we have to create an app in that app we create models then we run make migrations and migrate and then if we want to display this data we bring it into views.pi views.pi we handle all of the logic for looking up any given model in the database which is what we saw here we do need to handle exceptions like if things don't exist and every once in a while your exceptions are incorrect but that's okay because we can keep going once you actually handle the logic for any given view we bring that view into a url and we pass in the correct path now i did these things in conjunction to show you how these urls work but more than likely what you'll actually end up doing once you start getting good at this is you'll create a bunch of the views first and then worry about the url routing later so it's definitely a major subject of bringing url routing into views themselves and also doing it in a much more efficient way now i did mention one of the big things one of my challenges or my biggest problems with this is it's actually implementing all of the views it's importing that entire module and yeah it's nice that i can do dot notation to the view functions that i want in there but what if my profiles i needed to use the views in profiles as well so that actually gives me a little bit of a problem that i really do not prefer doing it this method it's just you'll see it a lot including in the django documentation so i actually prefer importing the specific functions that i'm going to use so home view as one detail view as another and then finally product api detail view as another okay so there we go and there it is okay so again we can test all of these views let's make sure that they're all imported correctly uh oops need that import statement there we go and there it is so products two works and then we're gonna go ahead and say api products2 also works cool so yeah let's go ahead and jump into the questions uh now just give me one second i'm gonna just switch over to the questions for this all right guys so thanks for watching uh the code part of this i'm gonna be going to more of the recent questions that have happened uh on this live stream so um be sure to ask those questions now things that aren't necessarily um related to what we just did is uh is something that that i'm probably not gonna cover so yeah uh let's see here this is a good one so what's the best way to send static files through nginx um so nginx has a way to serve static files from a specific url and going into a specific folder in there um i guess it's not exactly relevant to what we just talked about but it is um it is pretty easy to do although i recommend when you're using static files in django to use something like aws s3 or something like google cloud storage one of those things would be really good uh this live set yes so i will be putting it together a boot camp playlist now that there's three videos i guess i will have a playlist for that thanks for the question postgres or mysql you can use either django integrates with them both very easily okay so if we don't have any questions on the content here um then i'm going to be hopping off uh it looks like you guys are having a lot of side chat conversations which is awesome i'm glad that that was the case so let's see here i do have a few questions this one okay so this is a good question that's related to what we just talked about so the difference between id and primary key so let's go ahead and actually take a look at the code again so inside of models this is actually where the difference comes out okay so uh the id field itself is in django by default this can be overridden so you can actually change the id field so here is the id field that comes in by default but if you change it as in you don't necessarily use it or you pass in your own primary key then the field will be whatever you call it so on a lot of applications that i use i use something called dbid and i use models.um uuid field this is often one that i'll do and i'll pass in primary key equaling to true and then saying the default is something like uuid.uuid for right um so i mean there might be some syntax errors in here what that then does is this is now the primary key id is not the primary key any longer and so the lookup that i just did with this it will actually adjust for that so if you actually did change your field primary key or the model's primary key then it will absolutely adjust so this is related to the database and how it's stored in the database the id itself is just an arbitrary field name that we give the primary key it's arbitrary in the sense that you can change it but it's not arbitrary in the sense that it's very very common right so it's not something that you really have to worry about changing like it is very very common to use id as your primary key in databases not just in django but in a lot of places so there are instances where you might want to use something like db underscore id for a uuid field those instances would be if you are let's say you're integrating with another api that has an id that you also want to store and instead of changing the data that's coming from their api you can really just change how you store it especially if you want to use a uuid field instead of just a single integer i will say though using something like a uuid field if your database starts getting really really big it's going to get incredibly complicated to or not incredibly complicated but the lookups the time it takes to actually do the lookup for a uuid field will likely be longer than a single digit id or even if you know think about this a uuid field itself has a lot more characters in it than an id field would so if you have a million right so if you go up to a million entries that means that this will only have you know what seven digits um so uuid or dbid field will have more than that right off the gates so that's another consideration there a primary key is a flag in the database as well it's not just for django uh so hopefully that answers your question i'm not going to leave this in the code though uh that's a good question david thank you david rosen wow your name is very close to david rose which if you watch um shit's creek it's a funny tv show uh one of the funniest characters on there his name is david rose uh so that's pretty cool um anyways thanks david rosen i think you've been with me a few times and i'm pretty sure i haven't noticed this until now so sorry if i have um okay so let's see here okay why args and keyword args to each view even if you're not using it um so when in my opinion when you're using a function let's go ahead and look at the code again so when you're using any function in python if you're not sure what's actually being passed into that function i think using args and keyword arcs is a really clean way to ensure that you're not having problems with your function because you don't know what's happening like you're not having problems because of ignorance another way in other words i can actually come in here and do something like that for my home view and my home view should still run right so let's go ahead and take a look uh or sorry i have it mapped to search i don't have it actually as my home page but if i go in there it actually still renders through so even if you were like hey i forgot to put in the request well now you have args and keyword arcs and you can always print out what those things are to learn more about what's being passed right so if i refresh in there as well i now see that i am getting a argument not a keyword argument just a positional argument for the request itself now there's a lot of data about the request that i haven't covered just yet but i will um so yeah that is absolutely one of those things that's pretty cool right so that's why i use it now when you get more experience you will realize oh i don't actually need args and keyword args and i'll just pass in the actual arguments that are for sure coming in here so that's a that's another important distinction thanks for the question that's a good one very good very good okay so let me see here and let's go find another question tejas thank you this is a good one so can you explain the hd response f product what does the f represent here kumar so um i'm guessing maybe you don't have a lot of familiarity with string substitution in python so string substitution in python is really easy to do but i will show you um two ways on how you can do that exact same thing just by using python so let me just pull up the python shell here one second i almost should just leave this open um so i'm going to pull your question away so everyone can see this but here we are in the python shell so what you can do is with any given string you can pass in arguments here so let's say for instance abc is cool right and if a enter it's just abc is cool no big deal there but if i run dot format and say abc equals to you are and ur is cool well that doesn't make sense but this actually allows me to do string substitution for the variable of abc now this is also true for f strings so abc is cool i can also do that but in this case i'm not calling dot format it's actually looking for a variable of abc so if i said abc and say uh u or u is u is cool that's fine um anyway so if we do that now we've got that string substitution so that's just a very fairly simple python thing and you know if you're uncomfortable with this maybe the first 10 days or so of 30 days of python on my youtube channel would be something worth checking out so thanks for the question uh still relevant to what it is that we're talking about so i appreciate that thank you kumar okay uh next one i like this question um so wayne th this is like not always the easiest thing to answer at least at this point in what everyone else knows so for context depending on where you are business logic is things that relate to handling lookups or doing some sort of calculation in general right and so i would be tend to say that the best place to put it is in the views except if you need to reuse it a lot in that case then you'll use it in models i would say put very few business business logic things in templates um the views themselves and how you can actually run query sets um and lookups this is like the kind of logic that you're going to want to keep in the view itself if you put it in models which everyone doesn't realize this yet maybe but at some point we'll talk about how you can customize the things that you can do here so like let's say my custom lookup um you totally could do your custom look up like that and have a try block in there um but but it almost gets to a point where it's like well why have the try exception block in the model object itself when even the objects.get doesn't have that right so in this case you would want to keep this logic right in this view there are ways to shortcut both of these logical statements here but just in general you're probably gonna be putting in the views unless you're using it over and over again um but thank you for the question i think it's it's definitely relevant and i'm not even showing you what i was doing okay so let's try that again with me actually showing you um man that's funny okay so uh take a look here so this is that business business logic that i was talking about that's in a view and oftentimes you'll use the obj equals to product objects dot my custom lookup right so you absolutely could put this try block into that custom lookup but it actually doesn't make sense it makes a lot more sense to do it in the view so when in doubt put the business logic in views unless you have a really good reason to to not do that so hopefully that answers your question wayne thank you very much next one is it possible to not show the dynamic urls to the user yes so let's go ahead and take a look at what i think you're asking so when you actually come in here this is showing all of the url patterns i think you're asking can you hide this from a user well actually that will happen by default once you go into production so as you see here you're seeing this error because you have debug equals to true so if you had debug equals to false then you'll see the standard 404 page and we can actually take a look at that right so let's go ahead and jump in to what that would look like by going into our settings and just quickly switching this from true to false and now refreshing in here give it a second uh looks like i have a maybe i have some sort of error on the server there we go oh yeah so um we need to set our allowed host so this is a a new setting that we have for django just bear with me i'm just gonna do star for allowing every allowed host in there and we'll refresh in here and now it gives me this error so it's not gonna give me all of the possible urls that are in there when it is false okay so definitely don't do that star in production but you know when we're testing things out it's fine okay cool thanks for the question there all right so i'm only going to take a few more questions here um and then i'm going to hop off because it's going to be about an hour i've got a lot more questions i'll i'll try and do a live q a later today but it's it's kind of hard to do this and a live q a in one day uh but hopefully i can get it done because i actually want to prepare and everything for tomorrow for day three and hopefully have it a little bit better completed than what what would happen here today um okay so let me see here uh-huh okay and looks like uh i need to just jump on some questions on here so um we'll be doing unit tests in the code camp yes we will absolutely um what's the difference between one-to-one and foreign key so one-to-one is a type of foreign key so that's definitely not relevant to what i did um you're like is there a way to wash it all over yes you can actually rewind it all the way back you should be able to rewind all the way back right now but once this is done i will definitely be putting this on my channel so uh just like day one it's on my channel so yeah um i keep getting this question about rest django rest framework and authentication um i do not intend to cover django rest framework in this series the django bootcamp there's just so much to cover related to django that actually covering the rest framework is outside the the context of what we're doing here but i will try and put in api or json related requests as much as possible like i already did oh so this is a good question um what's the difference between try and catch which is actually in in python speak that's try and accept um versus if and else so when there's a exception that happens like there's actually a problem that's raised specifically by the code um it's it's a lot different than doing a condition statement right so that means that somewhere in the code it's saying hey there's a problem with what you just did that's called an exception that's true in javascript it's also true in python um it's true in a lot of languages so the code itself is raising a problem this is different than a condition statement where it's if and else if and else a conditional or a control flow statement like that is typically handling some sort of um some sort of like request or in the case of my urls if i said like oh if it's an id between 1 and 10 do this if it's an id between 10 11 and 100 do this right that's a condition there's no problem with the code per se but a conditional statement inside of if or else can actually raise an exception itself so a good example of that would be the raising of http 404 that is actually raising the page not found exception django just knows how to handle it and shows that that 404 page itself hopefully that answers your question uh so thanks for that andrus thank you for watching i'm glad you enjoy the effort i'm putting forward uh the funny thing is the live stuff i you know i haven't really taught live a whole lot and of course that's when the bugs are going to happen so i do appreciate you guys hanging out for that uh roman ask is sqlite3 for database enough when you go into production no you do not want to use sqlite3 in production in my opinion there's a lot of security problems with sqlite3 if for some reason somebody was able to get on to your server they would be able to actually just copy your sqlite3 really easily um or if you accidentally push it onto a github again same thing it's not an incredibly secure database there there are a lot of things that you can use sqlite34 so if it's not incredibly sensitive data then by all means use sega light 3 as a database but really you'd want to use something like postgresql or mysql to handle that so thanks for the question um that that is that is actually not that hard to set up in django itself there's just a few configuration items you need to do in settings up pi for postgres sql or mysql assuming you already have one of those servers or one of those database servers actually running okay so next question can we style the 404 slash error messages you absolutely can um and and we'll talk about that in the template section tomorrow we'll talk about how to do styling and all the things related to templates as well as the built-in template pages that django has like a 404 page and a 500 page um let's see here next question it does not allow the user to submit a negative number uh yeah sorry i didn't follow that thread and i used to get confused if args and keyword orgs are mandatory please tell everyone about the star and the two stars uh yeah so this is actually important as well again it's going back to sort of but when you look at a view or any actually any python function args right here are for keyword or excuse me positional arguments so my function that is abc you know one two three and whatever positional arguments you're using they can actually be mapped to keyword arguments as well a keyword argument would be saying like abc equals two one through one two three so this is actually a keyword with an argument on it um and that actually always goes into keyword args where positional arguments often go into args itself or keyword arts right i mean or actually they don't go into keyword args unless it's declared as a keyword argument uh this definitely can get a little bit confusing but the name args and the name keyword args actually has they're a little bit arbitrary you can call it a and k the things that are important are the star and the double star so it's very common to just call it args or arguments positional arguments and keyword arguments uh so hopefully that clarifies that question okay um so if there's not any last questions here um that are incredibly related to this yeah so people are asking about redis you absolutely can use redis with django that's definitely outside the context of what we're trying to do here in the django boot camp so but thanks for the question it's it's really good for caching you can use it for caching but you can also use it for delaying tasks to other times so i'm going to be releasing a series called time and tasks at some point that will cover that but anyways so that's it for day two and covering views if you have a lot of questions still please bring them tomorrow for the q a session same time tomorrow and pretty much the same format jumping in to handling how templates work so thanks again for watching guys and i will see you

Channel: CodingEntrepreneurs

Views: 21,074

Rating: 4.9769783 out of 5

Keywords: django, django-bootcamp, ecommerce, django3.1, python 3, web application development, python web apps, djangocfebootcamp2020oc, live coding, live stream

Id: T5jI9VgjJOQ

Length: 62min 1sec (3721 seconds)

Published: Tue Oct 06 2020