another thing you guys have asked about a lot is, is how you choose between web frameworks. now, remember the framework is generally the key step that sits between your program and the internet. now, in this class we've been using the google app engine frame work, which is basically called web app 2, which i found really nice. this handles, basically, basic http, kind of the scheduling, like the threading issues, you know, handling multiple requests at once. parsing basic headers, basically looking for things out of the get request or
the post request and putting them into these, like, request objects. turning your response object into the appropriate http to send to the browser. the url mapping and all of that stuff is really helpful. various degrees of web framework that give you more or less control and require you to do more or less work. the level that we've been working on in webapp2 is the level where i, i really like to be. the things that i, i really like about it are that we have direct access to get and post.
some frameworks kind of hide this from you, and i think it's really important that you are explicit about which method you're handling a get or a post. if you're thinking about the web in that way, your websites will generally make more sense. you won't make the mistakes of having, or you won't as easily make mistakes as having your, you know, your gets modify the database and then getting cached weird and, you know, your forms not submitting properly. understanding webs and web applications at the kind of method level, i think, is very, very important.
we've got direct access to the request. you know, this means things like headers. yes, there are convenience functions for setting cookies and getting cookies, but you can also manipulate the headers directly. sometimes you'll want to do something funky with content type or content length. then if the web framework don't let you do that, it can be really frustrating. you can't build the site the way you want to. so i find this kind of low level stuff is really helpful. but it's not so low that you're dealing with,
like, http versions and host headers unless you really want to. there are kind of features that a lot of frameworks do that i think that are non-important. this is strictly in my opinion. things like sessions, caching, some have automatic forums, database orm stuff. i don't like working with these because i find every time i use something like this, it's very soon after that i need a custom behavior. i want to handle sessions differently, or i want to cache things differently, or my forms don't fit the way the author thinks forms should work.
or, you know, the orm can't express queries that i want to express, or won't let me cache the way i want to cache certain queries. so i find this sort of stuff is a little too high level for me and i always end up rewriting it anyway. to me, the important things are basic http, having access to headers, and get and post. i almost never use pre-built session things, and caching, forms, and database stuff. in every experience i've had, in the long run,
i end up getting frustrated and i have to rewrite something that would have just been simpler to do in the first place. i generally don't like magic. when you look at some code and it just seems too magical, like it did all of this stuff for you and you're so far away from the request that you don't actually know what happened, that's a terrible way to write web software. you're not going to be able to scale it properly. you're not going to know why something breaks when it inevitably does. and it's going to take you,
i think ultimately it will cost you more work than just thinking through each of these problems on your own. sometimes, it's a good way to get started. something i didn't discuss here are the notion of templates. template languages come in all varieties. i am partial to one on python called mako. what we've been using in this class is ginja 2, and ginja's also been great. i think that the discipline here when you're using templates is making sure you separate code from templates.
a lot of these template systems allow you to put arbitrary code in them or complicated logical structures, if and for and while. try to keep it to the, the amount of code in templates to a minimum. you've got this whole language you know, in our case, python. that's a very, very powerful langauge, you can do all sorts of things. why would you use a broken subset of that in your templates? any complexities should be actually in your python code and not in your template code. didn't come up much in
this class because most of the rendering code we're using was fairly simple. it's really easy to just throw complete objects and big data structures and unwind them and, and navigate them in your template code. and that's something that's just really difficult to maintain. i wouldn't recommend doing that. templates are great, but use them with care. use them for just generating your html. or just generating your css. or whatever you're using it for.
and try to keep the code in the actual programming language.
Tidak ada komentar:
Posting Komentar