pasteob.ReqAddon (вопросы)
u960
буду признателен, если вы мне кое что обьясните на русском )
вопросы наверное достаточно глупые, но всё же:
1. Чем плох вариант с одной функцией, и почему нужна декомпозиция/
разложение?
2.
if message:
return send_message_app
else:
return the_form_app
Почему в таком варианте нельзя аргументами передавать запрос и данные
из приложения?
Допустим как нить так: send_message_app(req, vars()). В пятом решении,
передается каждый аргумент отдельно, а почему нельзя словарем всё
передать? И зачем декоратор на каждую функцию?
3. Почему везде встает проблема изменения данных запроса, и не
возможности использовать измененные данные в другом приложении. Мне с
пхп прошлым и настоящим :) не совсем понятен этот момент. Есть данные
из формы в массиве $_POST, он суперглобален виден везде:
function a() {
$name = $_POST['name'];
$_POST['name'] = $name . $name;
}
function b() {
$name = $_POST['name']; // тут уже новое значение
}
Ну да, старое значение потерялось безвозвратно, но тогда запишем новое
значение с новым ключом
$_POST['a.name'] = $name . $name.
Sergey Schetinin
> Пытаюсь осилить вашу переписку на английском языке,
> буду признателен, если вы мне кое что обьясните на русском )
> вопросы наверное достаточно глупые, но всё же:
>
> 1. Чем плох вариант с одной функцией, и почему нужна декомпозиция/
> разложение?
1. Выходит слишком большое тело функции
2. Разложив приложение на несколько это отдельные приложения можно
использовать отдельно
> 2.
> if message:
> return send_message_app
> else:
> return the_form_app
> Почему в таком варианте нельзя аргументами передавать запрос и данные
> из приложения?
> Допустим как нить так: send_message_app(req, vars()). В пятом решении,
> передается каждый аргумент отдельно, а почему нельзя словарем всё
> передать? И зачем декоратор на каждую функцию?
В этом варианте предполагается что send_message_app / the_form_app это
просто WSGI приложения -- в них данные так нельзя передавать, потому
что нарушает стандарт.
В случае с передачей отдельно упоминается что можно передавать
спец-обьектом или словарем. Это недостаточно хорошо потому что 1.
нарушаем стандарт 2. нет декомпозиции -- за создание этого словаря
оказывается ответственно конкрентное приложение.
> 3. Почему везде встает проблема изменения данных запроса, и не
> возможности использовать измененные данные в другом приложении. Мне с
> пхп прошлым и настоящим :) не совсем понятен этот момент. Есть данные
> из формы в массиве $_POST, он суперглобален виден везде:
>
> function a() {
> $name = $_POST['name'];
> $_POST['name'] = $name . $name;
> }
>
> function b() {
> $name = $_POST['name']; // тут уже новое значение
> }
> Ну да, старое значение потерялось безвозвратно, но тогда запишем новое
> значение с новым ключом
> $_POST['a.name'] = $name . $name.
Речь не о изменении данных в запросе, а о "data not trivially derived
from the request", то есть данные которые нужно *извлекать* из
запроса, то есть посмотреть в post, в кукизы, возможно в настройки,
может вычислить из других параметров итп. Скажем куки распарсеные в
сессию и всё такое прочее.
--
Best Regards,
Sergey Schetinin
http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter
Алексей С.
> 2010/3/13 u960 <phli...@gmail.com>:
>> Пытаюсь осилить вашу переписку на английском языке,
>> буду признателен, если вы мне кое что обьясните на русском )
>> вопросы наверное достаточно глупые, но всё же:
>>
>> 1. Чем плох вариант с одной функцией, и почему нужна декомпозиция/
>> разложение?
>
> 1. Выходит слишком большое тело функции
> 2. Разложив приложение на несколько это отдельные приложения можно
> использовать отдельно
то есть весь сыр бор в том, чтобы разбить одно WSGI приложение, ну
кучу маленьких WSGI приложений,
которые можно использовать отдельно?
>
>
>> 2.
>> if message:
>> return send_message_app
>> else:
>> return the_form_app
>> Почему в таком варианте нельзя аргументами передавать запрос и данные
>> из приложения?
>> Допустим как нить так: send_message_app(req, vars()). В пятом решении,
>> передается каждый аргумент отдельно, а почему нельзя словарем всё
>> передать? И зачем декоратор на каждую функцию?
>
> В этом варианте предполагается что send_message_app / the_form_app это
> просто WSGI приложения -- в них данные так нельзя передавать, потому
> что нарушает стандарт.
>
> В случае с передачей отдельно упоминается что можно передавать
> спец-обьектом или словарем. Это недостаточно хорошо потому что 1.
> нарушаем стандарт 2. нет декомпозиции -- за создание этого словаря
> оказывается ответственно конкрентное приложение.
>
а вообще имеет смысл делать the_form_app отдельным WSGI приложением?
в нашем случае это получается html шаблон с распиханными по умолчанию данными,
и для каждого случая будет своя html форма(ну кроме форма авторизации,
или фидбэка, которые более менее стандартизированы)
>
>> 3. Почему везде встает проблема изменения данных запроса, и не
>> возможности использовать измененные данные в другом приложении. Мне с
>> пхп прошлым и настоящим :) не совсем понятен этот момент. Есть данные
>> из формы в массиве $_POST, он суперглобален виден везде:
>>
>> function a() {
>> $name = $_POST['name'];
>> $_POST['name'] = $name . $name;
>> }
>>
>> function b() {
>> $name = $_POST['name']; // тут уже новое значение
>> }
>> Ну да, старое значение потерялось безвозвратно, но тогда запишем новое
>> значение с новым ключом
>> $_POST['a.name'] = $name . $name.
>
> Речь не о изменении данных в запросе, а о "data not trivially derived
> from the request", то есть данные которые нужно *извлекать* из
> запроса, то есть посмотреть в post, в кукизы, возможно в настройки,
> может вычислить из других параметров итп. Скажем куки распарсеные в
> сессию и всё такое прочее.
то есть нужно одним выражением извлечь какое то значение где бы оно не
находилось?
что то типа:
name = getvar(name)
def getvar(var):
...
v = req.GET[var] | req.POST[var] | sys.environ[var]
....
return v
>
>
> --
> Best Regards,
> Sergey Schetinin
>
> http://s3bk.com/ -- S3 Backup
> http://word-to-html.com/ -- Word to HTML Converter
>
> --
> Группа: http://groups.google.com/group/better-python-ru
> Отписка: better-python-...@googlegroups.com
Sergey Schetinin
> 13 марта 2010 г. 14:35 пользователь Sergey Schetinin <mal...@gmail.com> написал:
>> 2010/3/13 u960 <phli...@gmail.com>:
>>> Пытаюсь осилить вашу переписку на английском языке,
>>> буду признателен, если вы мне кое что обьясните на русском )
>>> вопросы наверное достаточно глупые, но всё же:
>>>
>>> 1. Чем плох вариант с одной функцией, и почему нужна декомпозиция/
>>> разложение?
>>
>> 1. Выходит слишком большое тело функции
>> 2. Разложив приложение на несколько это отдельные приложения можно
>> использовать отдельно
>
> то есть весь сыр бор в том, чтобы разбить одно WSGI приложение, ну
> кучу маленьких WSGI приложений,
> которые можно использовать отдельно?
Приблизительно так. Но вообще разбиение может быть и не на WSGI
приложения, а любое.
>>
>>
>>> 2.
>>> if message:
>>> return send_message_app
>>> else:
>>> return the_form_app
>>> Почему в таком варианте нельзя аргументами передавать запрос и данные
>>> из приложения?
>>> Допустим как нить так: send_message_app(req, vars()). В пятом решении,
>>> передается каждый аргумент отдельно, а почему нельзя словарем всё
>>> передать? И зачем декоратор на каждую функцию?
>>
>> В этом варианте предполагается что send_message_app / the_form_app это
>> просто WSGI приложения -- в них данные так нельзя передавать, потому
>> что нарушает стандарт.
>>
>> В случае с передачей отдельно упоминается что можно передавать
>> спец-обьектом или словарем. Это недостаточно хорошо потому что 1.
>> нарушаем стандарт 2. нет декомпозиции -- за создание этого словаря
>> оказывается ответственно конкрентное приложение.
>>
>
> а вообще имеет смысл делать the_form_app отдельным WSGI приложением?
> в нашем случае это получается html шаблон с распиханными по умолчанию данными,
> и для каждого случая будет своя html форма(ну кроме форма авторизации,
> или фидбэка, которые более менее стандартизированы)
Вообще это просто пример. Но и необходимость разбиения кода на
логические блоки я какбы даже не буду отстаивать, это не тема для
обсуждения.
Нет. Речь о извлечении данных вообще. Речь о том чтобы эти данные
можно было потом поменять. Там в обсуждении расписано с многих сторон
же. В частности сказано:
[...] The purpose is having an elegant solution for extracting some data
that may be used in multiple places. Being able to persistently edit
that data. Essentially having something as convenient and unfussy as
local namespace, which is not *that* local.
Я думаю тут вопрос опыта -- если еще не стоят вопросы на которые некое
решение отвечает, то возможно нужно временно его отложить пока не
станет понятней сама задача.