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.