|
60
|
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. |
