Mercurial > cgi-bin > hgweb.cgi > tincan
comparison doc/philosophy.rst @ 60:682cd33e564c draft
Documentation (incomplete).
author | David Barts <n5jrn@me.com> |
---|---|
date | Sat, 08 Jun 2019 07:43:15 -0700 |
parents | |
children | 55828c01e38f |
comparison
equal
deleted
inserted
replaced
59:60907204a265 | 60:682cd33e564c |
---|---|
1 ********** | |
2 Philosophy | |
3 ********** | |
4 | |
5 ================= | |
6 Be WSGI Compliant | |
7 ================= | |
8 | |
9 It's the default standard for Python web frameworks. | |
10 Only a fool wouldn't support it. | |
11 | |
12 ======================== | |
13 Don’t Reinvent the Wheel | |
14 ======================== | |
15 | |
16 TinCan is mostly Bottle and Chameleon. Why rewrite the basic guts of an | |
17 application server, when they’ve already been written many times? Why | |
18 write a new templating engine, when there’s existing ones out there? | |
19 TinCan tries to leverage existing software as much as possible. | |
20 | |
21 ====================== | |
22 Keep It Simple, Stupid | |
23 ====================== | |
24 | |
25 I wanted to get on with the business of actually *using* TinCan to do things, | |
26 so I didn't clutter it up with extra features that would be difficult to | |
27 implement. (That's why there's currently no way to choose alternate templating engines | |
28 to Chameleon. I tried to do that, and it proved overly complex. Maybe some day.) | |
29 | |
30 =========================== | |
31 Don't Be Gratuitously Bossy | |
32 =========================== | |
33 | |
34 TinCan is not tightly coupled with an ORM, and never will be. I personally dislike | |
35 ORM's, and | |
36 `I am not alone <http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern>`_. | |
37 Moreover, not all web applications need to use an SQL database in the first | |
38 place. | |
39 | |
40 This is of no loss, even for those who prefer to use an ORM, since | |
41 it is easy enough use an ORM with TinCan (just add it to the script you make | |
42 to load the webapp, and include the ORM in the webapp's ``config`` dictionary). | |
43 | |
44 =========== | |
45 Code-Behind | |
46 =========== | |
47 | |
48 It's maligned by many, but I personally like it, and it | |
49 does *not* necessarily mean repudiating the MVC paradigm. | |
50 | |
51 ===================== | |
52 Don't Repeat Yourself | |
53 ===================== | |
54 | |
55 One of the things I dislike about most Python web | |
56 frameworks is that I'm always tiresomely repeating "this is route foo, serviced | |
57 by controller foo \(which defines variables bar, baz and blort\), which uses template foo | |
58 \(which renders variables bar, baz and blort\)." This is completely unnecessary; | |
59 the relationships should be obvious by virtue of the similar names. The framework should figure | |
60 it out and just "do the right thing" by default. | |
61 | |
62 ============================ | |
63 MVC Comes in Different Forms | |
64 ============================ | |
65 | |
66 If you show a little discipline, the template page will describe how data | |
67 is presented to the user, and how he or she can interact with it. A view | |
68 by any other name is still a view. The code-behind will tie that view into | |
69 the underlying business logic, and bridge the gap between the two. A controller | |
70 by any other name is still a controller. | |
71 | |
72 If you don't show discipline, you can clutter your templates up with bits | |
73 of Python code that represent controller logic, and clutter your controller up with | |
74 bits of presentation details. Of course you can. That's not the framework's | |
75 fault; that's the programmer's fault. Bad code can be written in any language, | |
76 for any platform. | |
77 | |
78 ================================================== | |
79 The Alternative is PHP or CGI, not Django or Flask | |
80 ================================================== | |
81 | |
82 I'm not the only one out there who doesn't like all the repeating yourself | |
83 that most MVC frameworks make you do. There's still *a lot* of developers | |
84 out there writing CGI scripts or using PHP, because CGI and PHP don't make | |
85 you do all the busywork that frameworks do. (Can they be blamed? It really | |
86 feels silly when all you want is to get a quick, small site up.) | |
87 | |
88 That's a pity, because CGI is hideously inefficient and PHP is, well, just | |
89 plain hideous. \(A root namespace with literally *thousands* of builtins | |
90 cluttering it up, builtins with *no* consistent naming convention? Ugh!\) | |
91 | |
92 Hopefully, by making it easier for people to code efficient web sites using | |
93 a well-designed language that's easy to learn, I'll encourage more people | |
94 to create efficient sites in a well-designed language. If not, well, at least | |
95 I'll encourage *myself* to do so. | |
96 | |
97 ============================================ | |
98 Meaningful Error Messages (If You Want Them) | |
99 ============================================ | |
100 | |
101 Bottle can be notoriously tight-lipped about what's going wrong if and | |
102 when things go wrong. (And when you're developing and debugging code, | |
103 things go wrong). TinCan tries as hard as possible to catch errors and | |
104 log them. Enable logging, and when you see a 500 error, you will almost | |
105 always have a log file with a traceback in it helping to pinpoint the | |
106 cause. | |
107 | |
108 That is, assuming you enable logging. By default, it is turned off, simply | |
109 because WSGI provides no default place for errors to go. |