Vsem privet!

Poyavilsa takoy vopros..
Nuzhno peredat parametri metodom POST ot odnogo skripta k drugomu
bez ispolzovaniya formi. Kak eto sdelat?

Poisk v base foruma ne ispolzoval iz-za translita.
U kogo est idei budu vsemu rad.

S uvazheniyem,
Illya Konovalov

Задачу долго описывать. Я знаю что в этом случае можно и без
передачи от одного скрипта к другому, но если бы было
сравнительно простое решение это бы сэкономило мне время.
Вот почему я и спрашиваю знает ли кто-нибудь как это
делается.

Есть форма в которой уже может быть довольно таки много
введённой информации. Форма отвечает за за внесение информации
в базу. Есть ещё одна примерно такая же форма для изменения
существующей "записи" в базе. Есть 4 кнопки у каждой из форм,
на каждую функцию/форму по одному скрипту. 1 кнопка это
нормальный submit, 3 других отвечают за изменение списка
типов ошибок(это всё bug tracking system). При нажатии на
такую кнопку вся уже введённая информация должна сохранятся
в базе, т.е. временное сохранение данных и потом, после
добавления нового типа ошибок, данные снова берутся из базы
и пользователь дальше продолжает редактировать данные,
которые были сохранены в базе, при этом в списке у него
уже доступен для выбора новый тип ошибки, который он ввёл.

Так вот..я хотел бы, чтобы скрипт добавления ошибки после
того как он распознал кнопку добавления типа шибки брал
все данные из формы и передавал их другому скрипту, к примеру
temp.cgi, который бы отвечал только за процесс временного
сохранения информации в базе, добавления нового типа ошибки
и возврата обратно к "незаконченной" форме. Точно так же с Updatoм,
скрипт апдейта, назовём его update.cgi, брал бы все данные
из формы и передавал бы их temp.cgi, который бы выполнял
только свою задачу.

Другой вариант, к которому я уже сегодня хотел прибегнуть это
в каждом скрипте, и в add.cgi, и в update.cgi вставить такой механизм.
Т.е. чтобы эти скрипты плюс к своей прямой задаче ещё и выполняли
временное сохранение и добавление новых типов ошибок. Но
этот вариан громоздкий.

Можно было бы много чего ещё с формами придумать, но думаю
оптимальным бы вариантом была передача данных от скрипта скрипту.
Может модуль какой стандартный есть. Ресурсы это не проблема,
функция добавления новых типов в режиме редактирования ошибки
не будет вызываться часто. Это всё для безопасности, чтобы народ
не терял информацию, если вдруг пользователь вводил данные, а
потом посмотрел в списке типов и увидел, что нужного ему/ей типа не
существует, чтобы не нужно было всё заново вводить.

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

Надеюсь кто-то что-то понял из этого текста..
Завтра уже нужно двигаться с конкретным решением.

Жду ответа.

С Уважением,
Илья

ЗЫ Извиняюсь, что предидущее сообщение начал в неспокойном тоне.

KsnkНе очень понятно, а чего-ж тут такого уникального и непонятного?

add выводит пустую форму.
update выводит форму, заполненную предварительно прочитанными данными
temp сначала заполняет временную таблицу, а затем делает то-же, что и update.
Ты, вроде, сам все так и написал :)

Можно только порекомендовать писать не несколько скриптов, а только один,
и разбираться что-ж от него требуется с помощью параметров. Можно
сэкономить пару строк кода :-)

Может оказаться, что совсем необязательно сохранять все во временной базе.
Можно хранить введенные значения в самой выдаваемой форме, про value у тега
input, наверное слыхал?

Вы правы, Ksnk, я совсем не подумал о том, что абсолютно все данные
можно хранить как hidden, во временной форме, отвечающей за добавление
новых типов. value у меня стоит везде в апдейте, так что про это я слыхал :)

Но действительно, мнение со стороны иногда важно, т.к. бывает сам не видишь
простых вещей и всё больше улгубляешься в обдумывание сложных вариантов.
Я уже думал о текстовом файле, т.к. не желательно, чтобы в базе был мусор
и пробелы в поле id, в случае, если человек обрывает процедуру добавления
типов..

В общем ещё нужно над этим вариантом подумать и скорее всего всё буду
передавать как hidden и если пользователь сам обрывает апдейт типов то
сам виноват в потере данных..

Спасибо! :)


Илья

4m@t!cХоть убейте - не пойму, зачем таскать данные от клиента к серверу (причем данные на клиенте изменяться не будут), если их можно хранить на сервере????
----------------------------------------
Артисты не приехали, приехали цыгане

Дорогой 4m@t!c, давайте конкретное предложение, где и что будем хранить???

4m@t!cПо-моему я все написал. Неизменяемые данные, полученные от клиента в процессе сеанса хранить на сервере. Способ хранения? Да сколько угодно! Сессии, БД, файлы.
Объясните себе да и мне, в чем глубокий смысл передать на клиента заполненные им же поля, что бы он их не мог не видеть не редактировать?

Всё хранится в БД. Но речь здесь идёт о временном хранении информации.
И в этом случае проще передавать данные как hidden и по окончанию
редактирования списка типов переходить обратно на редактирование
уже внесенных данных, при этом вообще избегая хранение данных
в тектовых файлах, о которых я писал.. или в базе.

Зачем хранить данные в файле или БД, если данные эти будут находиться
в подвешенном состоянии очень короткое время? А потом, когда отчёт
дописан/форма полностью заполена данные будут добавлены в базу
как и при нормальном добавлении или апдейте..

Кстати, 4mat!c, Вы когда о сессиях говорили то думали как здесь их
вообще применить и зачем, если при этом всё равно нужно писать
в БД или файл? К тому же тот же пакет CGI::Session не поддерживает
PostgreSQL.. Вот и вопрос.. зачем всё усложнять, скорости о этого
не прибавится + лишнее программирование, лишние ресурсы.
И всё из-за функции, которая будет довольно таки редко использоваться..?

Ок, 4mat!c, теперь понятно от чего у нас расхождения во мнениях.
Я не сказал, что этот софт будет использоваться только внутри
тех. отдела, т.е. в интранет. Администратора также не будет,
т.е. в принципе каждый работник может добавлять отчёт об ошибке.
Всё это работает под Линуксом и для использования системы
нужно ввести логин и пароль. Есть логи веб-сервера + логи
самой системы. Ресурсы не имеют большого значения.
Траффик и частота использования системы сравнительно низкие.

Исходя из этого отпадает проблема безопасности, к примеру hidden, а
также проблема ресурсов. Важным пунктом является завершение работы
над проэктом в короткий срок.

Упрощённый вариант алгоритма..
1. Посылаем неполностью заполненную форму
2. Проверяем данные(частично, т.к. нас не волнует временная информация)
3. Открываем страницу редактирования типов с данными из 1. как hidden
4. Отсылаем форму с данными о новом типе + наши hidden поля
5. Заносим новый тип в БД
6. Открываем форму из пункта 1. заполненную нашими hidden значениями
(суть в том, что теперь у нас в списке доступен новый тип ошибки)

7,8,9... Пользователь заполняет форму дальше, отсылает и вся информация
нормально обрабатывается, поля проверяются, данные добавляются в БД.

Такие вот дела..

А всё таки было бы интересно знать можно ли передать данные от одного
скрипта к другому ;)

Спасибо, DocAI, не знал, что есть такая штука. И для perl тоже кое-что есть.
Но проще, в данной ситуации, с cURL(oм) не будет, буду использовать обычные
hidden поля.

Однако cURL открывает заманчивые возможности.. этим Вы ответили на многие
мои вопросы. :)

Perl :) В следующий раз буду указывать в скобках.

Николай aka Motodorтогда читаем
Тык

Спасибо за хороший линк! :)