Веб-девелопмент

>> Поищи эпический опус на тему php vs perl

>Дай линк, тут оные постоянно

Жаль, сейчас что-то не могу найти... Довольно боянистый опус, на двадцать экранов английского текста без фанатизма и беря перл просто в качестве другой стороны, а не образца для подражания, автор просто вклочья разносит пыхпых. Вообще гугл выдает почти два с половиной миллиона ответов на запрос "perl vs php". Я думаю мало где этот "vs" выходит в пользу последнего ;) Вот например неплохой материал, со ссылками на "learn more": http://www.tnx.nl/php.html

>> Первый пункт решения этой проблемы -- грамотная архитектура.

>И это конечно же... MVC??????77 Ты раскрой тему то...

Сам по себе MVC тут не при чем. Я про архитектуру обработки форм в целом и применительно к тому коду в частности. Я не в курсе, как там щас круто и правильно генерить формы в пыхпыхе, но мне очень близок декларативный подход, ala джанга (хотя, конечно, не они первые это придумали и реализовали). http://docs.djangoproject.com/en/dev/topics/forms/#topics-forms-index -- если не читал, посмотри.

> Я думаю мало где этот "vs" выходит в пользу последнего ;)

А что перевесит: 1001 проблема безопасности, или "дешешева, сделаю к утру"?

> Вот например неплохой материал, со ссылками на "learn more": http://www.tnx.nl/php.html

Ничего нового не узнал, а помойку из функций можно и простить, ибо делали всем миром.

> но мне очень близок декларативный подход, ala джанга

Мне тоже, только без смешивания форм с кодом скрипта. На формы джанги дрочил раньше.

Вот внутри такой формы и создается запрос к SQL или еще чему, а в html отдается только id формы

>А что перевесит: 1001 проблема безопасности, или "дешешева, сделаю к утру"?

От задачи зависит. Так что можно в двух словах сказать так: если хочется делать "мегапорталы" на джумле за две ночи -- пыхпых вне конкуренции. А если цели повыше да посерьезнее, есть смысл присмотреться к чему-то более другому.

>помойку из функций можно и простить, ибо делали всем миром.

Многие языки "делали всем миром", но мало где такое твориться. Неймспейсы (точнее их отсутствие) -- вот причина. Ну и отчасти отсутствие самодержца, эдакого кормчего. BDFL, тысызыть.

>только без смешивания форм с кодом скрипта

Не понял.

> если хочется делать "мегапорталы" на джумле за две ночи -- пыхпых вне конкуренции. А если цели повыше да посерьезнее, есть смысл присмотреться к чему-то более другому.

Дык а на что сейчас больше спрос? Если посмотреть на что-то вроде weblancer.net, то именно мегапорталы за 2 дня и нужны. Сделаешь кеширование - говносайт уже и тормозить перестанет, большое количество людей принять сможет. Как часто нужно что-то большее? Онлайн-игру сделать конечно не выйдет, но как часто попадаются такие заказы?

> Неймспейсы (точнее их отсутствие) -- вот причина. Ну и отчасти отсутствие самодержца, эдакого кормчего. BDFL, тысызыть.

Ну повторю, это не самая большая проблема. Нет большой разницы, как именно писать имена функций.

> Не понял.

Я не люблю, когда в код пихается куча констант или включения других языков, вроде HTML-кода, описания таблиц в виде sql-запросов или описания форм. Не важно, хоть это html-формы, хоть qt. Код формы (я считаю) должен лежать отдельно и редактироваться независимо, а при инициализации просто считываем этот ресурс и распаковываем его в память.

>Дык а на что сейчас больше спрос?

Я с фрилансом, слава Богу, завязал еще на третьем курсе :) Так что не знаю, на что там спрос у полоумных дядь, размещающих заказы на сцайтах типа weblancer.net :) serious_cat.jpg

>Нет большой разницы, как именно писать имена функций

Для меня есть. Если код стандартной библиотеки языка похож на говно, программировать на таком языке неприятно. Хотя кому что нравится :)

>Я не люблю, когда в код пихается куча констант или включения других языков, вроде HTML-кода, описания таблиц в виде sql-запросов или описания форм. Не важно, хоть это html-формы, хоть qt. Код формы (я считаю) должен лежать отдельно и редактироваться независимо, а при инициализации просто считываем этот ресурс и распаковываем его в память.

Все с точностью так, как в нормальных фреймворках. Код формы декларативен и написан только в одном месте, вызывается в шаблоне одной примитивной конструкцией, в контроллере используется в ООП-стиле лаконично и удобно. KISS и DRY, красота да и только!

> Когда я увидел MAX_FILE_SIZE
Хм... а какое это имеет отношение к серверу вообще? Это ведь HTML,
говорящий браузеру что не фиг зря аплоадить больший файл, ибо сервер его не примет все равно.

> складывание файлов в директорию по умолчанию
Это про что?

> глобальные переменные из запроса
Ну если использовать фреймворки то такого нету.

> изобретение в формах с именами[]
А это чем плохо?

Про то что PHP спроектирован не последовательно и похож на просто сборку разных библиотек согласен. В нем нет никакой "философии".

> Я с фрилансом, слава Богу, завязал еще на третьем курсе :) Так что не знаю, на что там спрос у полоумных дядь, размещающих заказы на сцайтах типа weblancer.net :) serious_cat.jpg

А куда идут остальные? В Ъ-ынтерпрайз студии, которые потом распределяют свои проекты по тем же фрилансерам? Или в ИРЛ-конторки, где цены в 10 раз больше, а результат в 10 раз хуже? И еще хостинг норовят впарить по пятикратной цене. У меня знакомый так налетел - только хостинг на год ему встал в 5000р для сайта-визитки из 3 страниц.

> Для меня есть. Если код стандартной библиотеки языка похож на говно, программировать на таком языке неприятно. Хотя кому что нравится :)

Дык а чего там программировать? Оно же задумывалось как обработчик форм/темплейтер, причем с этим прекрасно справляется. Какие неймспейсы в шаблонизаторе, ты чего? Все остальное делает БД, ну или надстройки над ней.

> Код формы декларативен и написан только в одном месте

А теперь дай его дизайнеру, дабы он расположил поля в каком-то определенном порядке, засунул его в свой лейаут.

> Хм... а какое это имеет отношение к серверу вообще? Это ведь HTML,
говорящий браузеру что не фиг зря аплоадить больший файл, ибо сервер его не примет все равно.

А вот в том то и дело, что примет. Сервер может отменить отправку только _ДО_ начала получения тела, а тут лимит уже в самом теле.

Вот тебе пример:

POST /upload HTTP/1.1
Host: myhost
Expect: 100-continue
^^^^^^^^^^^^^^^^^^^^ - клиент ожидает согласия сервера
Connection: Keep-Alive, TE
TE: deflate, gzip, chunked, identity, trailers
Content-Length: 1746795
Content-Type: multipart/form-data; boundary=----------qpX9lM7so5jejEoSNQ536z

HTTP/1.1 100 Continue
^^^^^^^^^^^^^^^^^^^^^ - сервер соглашается и просит продолжать

------------qpX9lM7so5jejEoSNQ536z
Content-Disposition: form-data; name="MAX_FILE_SIZE"

30
^^^^^^^^^^^^^^^^^^^^ - и только после этого прилетает лимит в 30 байт.
------------qpX9lM7so5jejEoSNQ536z
Content-Disposition: form-data; name="userfile"; filename="34.flv"
Content-Type: application/octet-stream

^^^^^^^^^^^^^^ - а это уже заголовок файла, где размера тоже нет

В результате на сервер прилетело не 30 байт, а 100кб

Причем это зависит от клиента и заголовков, ибо при заливке через curl прилетает 1.7 метра (полный файл):

POST /upload HTTP/1.1
User-Agent: curl/7.14.0 (i686-suse-linux) libcurl/7.14.0 OpenSSL/0.9.7g zlib/1.2.3
Host: myhost
Accept: */*
Content-Length: 1746721
Expect: 100-continue
Content-Type: multipart/form-data; boundary=----------------------------4eebedfa93b4

HTTP/1.1 100 Continue

Это одна из тех самых вещей, которые defective by design. Только что проверил на своем сервере, используя сниффер.

И как говорил один и работников яндекса: "юзер уже потратил трафик, но ничего не получил, разве можно так издеваться над ним?"


> Это про что?

Это продолжение процедуры аплоадинга. Все файлы, независимо от того, нужны ли они тебе, аккуратно складываются в tmp сервера. А потом при надобности удаляются. Красота же!

> Ну если использовать фреймворки то такого нету.

Это теперь нету, а во времена php2 (когда я его начал изучать, потом скоро еще php3 вышел) это было номальной практикой.

> А это чем плохо?

А чем плохо ходить с голой попой на улице?


> В нем нет никакой "философии".

Это простой обработчик форм и темплейтер, который почему-то начали использовать как полноценную среду для программирования. Отсюда и вилы.

> А вот в том то и дело, что примет. Сервер может отменить отправку только _ДО_ начала получения тела, а тут лимит уже в самом теле.
Извини, я не так выразился, я имел ввиду само приложение, его серверную часть, а не веб-сервер. Понятно, что веб-сервер не при делах, это ведь не часть HTTP. И все же, какое это имеет отношение к PHP? Этот тег просто дает указание браузеру, не более.

> А чем плохо ходить с голой попой на улице?
Я все же бы хотел получить ответ на свой вопрос.

> Понятно, что веб-сервер не при делах, это ведь не часть HTTP.

OMG, а чем же ему еще заниматься?

> И все же, какое это имеет отношение к PHP?

Такое, что поток данных (форму, где все данные перемешаны) принимает именно похапе, уже разбирая на составные элементы - файлы, переменные, массивы и так далее. Если похапе видит в имени элемента [], то оно его сохраняет как массив, если видит MAX_FILE_SIZE, то его значение берет в качестве лимита и дропает файлы, которые больше него (но поскольку поля формы таки перемешаны, то на сервер прилетает ВСЕ). Вот и вся сказка.

> Этот тег просто дает указание браузеру, не более.

К браузеру этот тег имеет точно такое же отношение, как и другие элементы формы: он должен его просто передать на сервер. Сам браузер на него внимания не обращает (иначе бы он не должен был мне позволить начать загрузку).

> Я все же бы хотел получить ответ на свой вопрос.

Плохо это тем, что сервер берет инструкции для составления своих внутренних структур с клиента, которому вообще-то доверять нельзя. Клиентский запрос всегда может быть модифицирован, а значит сервер может его так интерпретировать, что построит (выполнит) совсем не то, что изначально задумывалось. Это как <input type="hidden" name="do" value="INSERT INTO ..... VALUES (this.form.name, this.form.message, .....)">, только не сильно страшное, например:

<input name="te[]" value="v1"><br>
<input name="te[]" value="v2"><br>
<input name="te[]" value="v3"><br>

foreach($_POST["te"] as $key => $value){
print "<li>$key -- $value";
}

А теперь убираем [] и при везении получаем варн с полным путем к файлу, номером и содержанием строчки с ошибкой, что можем использовать для дальнейшего анализа. Очень секурно, ага.

> OMG, а чем же ему еще заниматься?
Тег с max_file_size не часть HTTP. Так понятней?

> К браузеру этот тег имеет точно такое же отношение, как и другие элементы формы...
Хм... не знал что PHP обрезает файл по данному параметру, это они действительно зря придумали. Но к браузеру этот тег имеет отношение и может быть использован не только с PHP.
" If a browser supports this form field, it will not allow the user to choose a file that is larger than 1048576 bytes. So, the user does not have to wait for a file to upload to the server in order to find out whether it is too large or not."
http://www.developershome.com/wap/wapUpload/wap_upload.asp?page=php3

> Плохо это тем, что сервер берет инструкции для составления своих внутренних структур с клиента, которому вообще-то доверять нельзя...
В том то и прикол что доверять нельзя и входные данные проверять на корректность. Так что не вижу ничего страшного в данном подходе.

> Тег с max_file_size не часть HTTP. Так понятней?

Да, так понятней. Теперь понял, про что ты. Но ничто не мешало бы сделать POST /my_form_handler_no_more_92378642_bytes_per_post и вместо 100 статуса выдавать ошибку на законных основаниях. Надеюсь, теперь тебе тоже понятно.

> Но к браузеру этот тег имеет отношение и может быть использован не только с PHP.

Хм, первый раз такое вижу. Смотрим: http://www.google.com/search?q=site:w3.org+max_file_size - видны только заметки в рассылках, официальных спецификаций НЕТ. Подгонять браузер под похапе - это сильно.

А использовать с чем угодно можно, другой вопрос будет ли толк...

> В том то и прикол что доверять нельзя и входные данные проверять на корректность

А вот проверять то как раз нужно. Но в момент парсинга у сервера нету схемы, по которой бы он смог проверить и зарубать некорректную форму. А раз ее нет - он строит $_POST на основании данных с клиента, в результате получаем возможность засунуть в $_POST абсолютно любую структуру данных, в том числе и с массивами любой размерности. Вроде не страшно (пока), но мне по крайней мере это очень неприятно.

начни обязательно с ruby/CGI или python/CGI. потом напиши ченить с python/web.py и почитай буквари по django/rails

если начать сразу с чегото высокоуровневого то будешь незнать кому задавать глупые вопросы, и на всяких форумах с тебя будут смеяться

----------------
<input name="te[]" value="v1"><br>
<input name="te[]" value="v2"><br>
<input name="te[]" value="v3"><br>

foreach($_POST["te"] as $key => $value){
print "<li>$key -- $value";
}

А теперь убираем [] и при везении получаем варн с полным путем к файлу, номером и содержанием строчки с ошибкой, что можем использовать для дальнейшего анализа. Очень секурно, ага.

----------------
незачет. error_reporting(0) вас спасет, не говоря уж про проверку массива на существование и наличие правильных ключей

а не делать это можно для админа, которому и так все можно

> что-то вроде <input type="hidden" name="do" value="INSERT INTO ..... VALUES (this.form.name, this.form.message, .....)">, то с серверной стороны скрипты будут почти не нужны, ибо зачастую

Нет, так делать не стоит. Скрипты, aka middleware, являются необходимой частью информационной системы.

Теоретически, банкоматы тоже не нужны. Банки могли бы просто в условленное место класть пачку банкнот, из которой каждый клиент брал столько, сколько у него осталось на депозите. Но это ведь нужно постоянно помнить сколько у меня денег там осталось. Неудобно. В итоге, деньги лежат в банкомате, а банкомат сам разруливает контроль за состоянием депозита. Это называется *инкапсуляция*. А еще банкоматы позволяют проводить платежи вообще без участия банкнот. Благодаря этому появляется возможность, скажем, моментального пополнения счета на телефоне, что с реальными купюрами сделать было бы крайне сложно. Это называется *абстракция*. Такой вот OOD в банковской системе. :)

В мире web, аналогичную роль играет middleware.

> Хм... Что-то в этом есть...

Основная ценность фреймворков заключается в том, что в них уже заложены способы решения типовых задач (характерных для конкретной предметной области). Библиотеки же это лишь наборы инструментов, на базе которых решение нужно еще придумать.

PHP классный фремворк для работы с web-сервером. Еще он задумывался как шаблонизатор, но получился ниочем, т.к. в области трансформации данных рулят функциональные языки. А о остальном его ценность, как web-фреймворка, весьма сомнительна, поскольку он предоставляет лишь кучу библиотек.

> Нет, так делать не стоит. Скрипты, aka middleware, являются необходимой частью информационной системы.

pre/post-процессинг никто не отменял. В той же базе уже могут быть нужные триггеры.

> Это называется *инкапсуляция*

Ага, и она очень помогает, когда нужно завернуть неизвестные данные в какой-то конкретный шаблон.

> А еще банкоматы позволяют проводить платежи вообще без участия банкнот.

А еще NERO позвоняет не только прожигать болванки, но и редактировать аудио/видео/проводить транскодинг/рисовать обложки/выжигать надпись. А глюпые линаксоиды зачем-то придумали принцип, что одна программа должна решать только одну задачу.

что в них уже заложены способы решения типовых задач (характерных для конкретной предметной области).

Да чего мелочиться. Давайте сразу напишем типовые скрипты (типовой форум, типовые новости, типовую жумлу) и не будем страдать...

> Еще он задумывался как шаблонизатор

А больше от веб-фреймворка ничего и не надо. Процессинг форм (контроллер) и шаблонизатор (view). А дальше как выйдет...

><input type="hidden" name="do" value="INSERT INTO ..... VALUES (this.form.name, this.form.message, .....)">, то с серверной стороны скрипты будут почти не нужны, ибо зачастую кроме интерфейса к БД ничего и не надо... Разве это не прелесть?

да, ++9000, это прелестно!!

не могли бы Вы сообщить адреса некоторых сайтов, где такое уже сделано?