Как создавали сайты до Django и вообщем без фреймворков?

Question

[Akmat]

Если открывается тема о создания сайтов на Python все перенаправлет (большинстве случае) к Django, Flask и.т.д
Хотел бы узнать раньше как решали эти проблемы?
Хочу пойти с нуля до фреймворка.
Я думаю если иди с нуля то лучше буду понимать суть создания сайтов на Python и не только.
сейчас знаю
html,
css,
python,
ооп,
mysql,
Git,
немножка о веб-сервер nginx и cgi.
постепенно учусь.

Comments

[javedimka]

Если интересно как написать простой сайт(ну типо вообще простой) на питоне без фреймворков - у Лутца в "Программируем на Python" есть пример, кода на пол страницы.

[reus]

javedimka: Программирование на Питоне лутца лучше выбросить в топку и не тратить время на древнюю ересь. Хотя книга Изучаем питон то что надо

[javedimka]

reus: нормальная книжка

Answer 1

[PolinaRuRu]

в начале 2000-ых, я открывала notepad и писала там html-код. жесткий.
потом открывала другой notepad и писала там css-код.
потом это соединяла воедино.

Потом был шаблон наипростейшего форума на PHP со своей БД. Но шаблон форума был как черный ящик.
Потом через БД я научилась делать менее жесткие html- страницы. К примеру, запрос возвращал ссылку на картинку, в зависимости от вводимого значения.

Потом были сайты с FLASH-анимацией.

Прошло много лет.

Сейчас я пишу на питоне. Использую все возможные фрэймворки, какие только найду. Если не нахожу, то пишу сама. Сейчас я ненавижу веб-разработку, и все что с ней связано.
Пишу дэсктопные приложения, скрипты для работы с дэсктопными приложениями и для работы с БД.
Не нужно не использовать фрэймворки. Это не совсем правильно.
Для фана - да. Как некоторые художники сейчас сами делают акварель, а не покупают в магазине. Для понимания работы - не самый лучший вариант. Нужно двигаться вперед. Понимание черного ящика придет само со временем.

Answer 2

[Сергей Горностаев]

/me достаёт гусли, усаживается в позу сказителя

Сначала мы писали CGI-скрипты. Тогда ещё не на Python, на Perl. Это было время сильных мужчин. Тогда нельзя было быть web-программистом и не знать наизусть протокол HTTP. Впрочем, как и многое другое. Тогда ещё не было шаблонизаторов и html-код мы выводили пелёнкой принтов с экранированными строками. Не было ORM, с базой данных общались SQL-запросами. Не знать SQL тоже было нельзя. Потом был mod_perl. Потом FastCGI. А потом уже Python с WSGI. Если вы хотите разобраться в web-программировании без фреймворков, то на uWSGI вам и стоит обратить внимание. CGI-скрипт на Python тоже написать можно, но этот интерфейс уже не актуален.

Answer 3

[Dmitry Tallmange]

Как и на любом другом языке.
1. Непосредственно данные, их обработка и хранение. Реляционная модель - один путь развития. Нереляционный путь — другая модель. В итоге есть код, который умеет работать с данными: сохранять, доставать по запросу. Ещё это называют «бизнес-логикой».
2. Представление данных. Некий код, который на входе принимает «сырые» данные, на выходе отдает html/xml/xsl. То, что можно отдать браузеру или любому другому клиентскому устройству.
3. Код, связывающий эти две сущности. В терминологии MVC его ещё называют контроллером. Он решает за какими данными пойти и какому представлению их отдать на отрисовку.

Получилось очень похоже на описание модели MVC. По-моему, — наиболее верная архитектура.

Answer 4

[Astrohas]

Фреймворк - это каркас. Зачем создавать что либо без каркаса? По сути создавая сервисы без фреймворков, вы создаете свой собственный велосипдо-фреймворк пародирующий какой либо из существующих.
***
Для создания чистого "без фреймворков" берете какой нибудь CGI сервер, можно стандартный http.server, включаете режим php кодинга, и пишите

Answer 5

[alex maslakoff]

сами писали весь код, только то, что нужно, по-минимуму. сохраняли в библиотеках. переиспользовали.

сайт ведь -- это веб сервер, который отдает html страницы.

Answer 6

[asd111]

Чтобы идти с нуля нужно брать uwsgi или что нить в этом духе.
До uwsgi было 2 варианта:
1. запустить python на 80 порту и обрабатывать все самому;
2. накалякать на С мини сервер и на запросы с 80 порта запускать python скрипт.
Сейчас мы пришли к развитому второму варианту в виде uwsgi и тп.
Минисервер на С нужен для быстрой обработки входящих запросов и чтобы в python отдавать обработанные данные. Т. е. вместо сплошной строки http запроса отдавать распарсенные строки.