|
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
|
|
61
|
27 implement. (That's why there's currently no way to choose templating engines
|
|
|
28 other than Chameleon. I tried to allow that, and it proved overly complex. Maybe some day.)
|
|
60
|
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
|
|
61
|
49 does *not* necessarily mean repudiating the MVC paradigm (see :ref:`mvc-different-forms`).
|
|
60
|
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
|
|
61
|
62 .. _mvc-different-forms:
|
|
|
63
|
|
60
|
64 ============================
|
|
|
65 MVC Comes in Different Forms
|
|
|
66 ============================
|
|
|
67
|
|
61
|
68 If a programmer shows a little discipline, the template page will describe how data is presented to the user, and how he or she can interact with it. A view by any other name is still a view. The code-behind will tie that view into the underlying business logic, and bridge the gap between the two. A controller by any other name is still a controller.
|
|
60
|
69
|
|
61
|
70 If a programmer don't show discipline, s/he can clutter templates up with bits of Python code that represent controller logic, and clutter the controller up with bits of presentation details. Of course s/he can. That's not the framework's fault; that's the programmer's fault. Bad code can be written in any language, for any platform.
|
|
60
|
71
|
|
|
72 ==================================================
|
|
|
73 The Alternative is PHP or CGI, not Django or Flask
|
|
|
74 ==================================================
|
|
|
75
|
|
|
76 I'm not the only one out there who doesn't like all the repeating yourself
|
|
|
77 that most MVC frameworks make you do. There's still *a lot* of developers
|
|
|
78 out there writing CGI scripts or using PHP, because CGI and PHP don't make
|
|
61
|
79 you do all the busywork that most frameworks do. (Can they be blamed? It really
|
|
60
|
80 feels silly when all you want is to get a quick, small site up.)
|
|
|
81
|
|
|
82 That's a pity, because CGI is hideously inefficient and PHP is, well, just
|
|
|
83 plain hideous. \(A root namespace with literally *thousands* of builtins
|
|
|
84 cluttering it up, builtins with *no* consistent naming convention? Ugh!\)
|
|
|
85
|
|
|
86 Hopefully, by making it easier for people to code efficient web sites using
|
|
|
87 a well-designed language that's easy to learn, I'll encourage more people
|
|
|
88 to create efficient sites in a well-designed language. If not, well, at least
|
|
61
|
89 I'll enable *myself* to do so.
|
|
60
|
90
|
|
|
91 ============================================
|
|
|
92 Meaningful Error Messages (If You Want Them)
|
|
|
93 ============================================
|
|
|
94
|
|
|
95 Bottle can be notoriously tight-lipped about what's going wrong if and
|
|
|
96 when things go wrong. (And when you're developing and debugging code,
|
|
|
97 things go wrong). TinCan tries as hard as possible to catch errors and
|
|
|
98 log them. Enable logging, and when you see a 500 error, you will almost
|
|
|
99 always have a log file with a traceback in it helping to pinpoint the
|
|
|
100 cause.
|
|
|
101
|
|
61
|
102 (Note that WSGI provides no default means for logging errors, so if you're running TinCan via WSGI, it will be totally silent unless you pass ``tincan.launch`` a suitable logger. The simple test server created by the ``launch`` command always logs to standard error.) |
