![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Как открыть длинный URL в браузере?
Tack © (2008-12-09 22:31:00)ShellExecute при попытке открыть длинный URL обрезает его до 2083 символов.
А нужно стартануть URL длиной в 4К.
Подскажите, как обойти проблему, не используя внешние файлы (вроде загрузки из подготовленного html с редиректом)
Ega23 (2008-12-11 17:04:00) [1]
> Можно подумать в сторону XSL Transformations, подыскать
> енжин подходящий ...
Зачем? Я не генерю AJAX-ответы в виде HTML, я их в JSON-формате возвращаю, потом ему eval делаю - и у меня готовый JavaScript-объект, с кучей свойств.
А поскольку те же YUI-компоненты (от Yahoo) на чистом JavaScript написаны и данные в целом только такие данные и понимают, то такой вариант мне гораздо проще.
Фактически, у меня с сервера приходит что-то типа
var data1 = {
treedata:
[
{type:"Text", label:"Рыба", expanded:true, children:
[
{type:"Text", label"Судак", id:"f1"},
{type:"Text", label:"Окунь", id:"f2"},
{type:"Text", label:"Щука", id:"f3"},
{type:"Text", label:"Карась", id:"f4"}
]
},
{type:"Text", label:"Птица", expanded:true, children:
[
{type:"Text", label:"Орёл", id:"s1"},
{type:"Text", label:"Воробей", id:"s2"},
{type:"Text", label:"Ворона", id:"s3"},
{type:"Text", label:"Другая пцыца", id:"s4"}
]
},
],
menudata:[
{ text: "Добавить", id:"act1"},
{ text: "Изменить", id:"act2"},
{ text: "Удалить", id:"act3"}
]
};
И я, подставив в YUI.TreeView массив data1.treedata, а в YUI.ContextMenu массив Data1.menudata получаю готовое дерево с привязанным к нему контекстным меню. А данные и действия в меню - в зависимости от прав пользователя.
И мне нафиг не нужно заморачиваться, какой сейчас дизайн у страницы. Мне нужен один единственный div с определённым id, на котором это дерево с меню будет развёрнуто.
b z (2008-12-11 16:51:00) [2]
> Ega23 © (11.12.08 14:40) [34]
> Голый apache + cgi/fastcgi.
Можно подумать в сторону XSL Transformations, подыскать енжин подходящий ...
Ega23 (2008-12-11 14:40:00) [3]
> Кстати а вот микрософт заявило что пхп под иисом вертится
> шустрее чем на апач.
У меня нет никакого пхп. Голый apache + cgi/fastcgi.
b z (2008-12-11 14:36:00) [4]
> Ega23 © (11.12.08 14:27) [32]
> По условиям моей задачи, у меня только Apach + cgi/fastcgi
Когда-то у нас тоже была похожая ситуация, но мы решили ее подругому.
Составили документ в котором указали, что перейдя на другую платформу мы поимеем прирост производительности, скорость разработки (даже с учетом репликации серверов. - так оно было) и простоту поддуржки, ну как итог - эконом. выгоду. И послали его заказчику. Нам "поверили", в итоге мы получили премию в размере 2 окладов. :)
Кстати а вот микрософт заявило что пхп под иисом вертится шустрее чем на апач. Это я так, вроде там у вас кросплатформенность была.
Ega23 (2008-12-11 14:27:00) [5]
> Например асп.нет посмотрите.
По условиям моей задачи, у меня только Apach + cgi/fastcgi
b z (2008-12-11 14:23:00) [6]
> А в том, что всю страницу чисто на разметке формировать
Вы имеете ввиду весь код страницы стрингами конкатенировать? Такого уже давно никто не делает. Для этого куча движков написано. Например асп.нет посмотрите.
clickmaker (2008-12-11 14:21:00) [7]> А в том, что всю страницу чисто на разметке формировать
> - застрелиться можно. С другой стороны, на сервере лежат
> "шаблоны" страниц, в которых уже определены стили
так а в чем проблема на сервере это формировать?
грубо говоря, есть шаблон
<html>
%ADMIN_BUTTONS%
%USER_BUTTONS%
...
для обычного юзера %ADMIN_BUTTONS% заменяется пустой строкой. Это если какой-то скриптовый язык типа пхп.
В aspx это вообще решается установкой Visible контролам
clickmaker (2008-12-11 14:18:00) [8]> Подскажите, как обойти проблему, не используя внешние файлы
а если создать временный *.url файл и скормить его браузеру?
Ega23 (2008-12-11 14:07:00) [9]
> а смысл?
А в том, что всю страницу чисто на разметке формировать - застрелиться можно. С другой стороны, на сервере лежат "шаблоны" страниц, в которых уже определены стили, сделана какая-то предварительная разметка и т.д.
Грубо говоря, это всё-равно что ты модальную форму генеришь полностью из метода, ну типа:
procedure TForm1.InvokeSomeModalForm(Some_Params);
var
frm : TForm;
memo : TMemo;
btnOK, btnCancel : TButton;
begin
frm := TForm.Create(nil);
try
frm.SetBounds(....);
memo := TMemo.Create(frm);
memo.Parent := frm;
memo.SetBounds(....);
memo.Lines.Assign(Some_Params.MemoData);
btnOK := TButtonCreate(frm);
............
frm.ShowModal;
if frm.ModalResult = ....
finally
frm.Free;
end;
end;
Можно так сделать? Да легко. только каждую форму так описывать - гемор.
Вот, ИМХО, такая же фигня с полной генерацией разметки страницы на сервере.
b z (2008-12-11 14:01:00) [10]
> clickmaker © (10.12.08 15:52) [13]
> и почему это делается через GET, а не через POST?
Хм ... а как передать post посредствам [0], т.е. ShellExecute ... ?
> Ega23 © (11.12.08 13:54) [25]
> Путь 2.
А в чем смысл этих "плясок", зачем лишний раз делать запрос, если можно сразу сгенерить ... или вы чегото не досказали?
clickmaker (2008-12-11 13:59:00) [11]> в котором сформирован только набор кнопок, а не вся страница
> целиком
а смысл?
страница и так формируется целиком в момент, когда "Сервер переадресует пользователя на основную страницу"
путь, в котором сформирован только набор кнопок, имеет смысл только когда пользователь не покидает основную страницу. Что-то типа быстрого переключения юзера.
Ega23 (2008-12-11 13:54:00) [12]
> На самом деле, при передаче данных, которые не влезают в
> урл (или которые не желательно туда пихать), есть 2 способа:
>
> 1. AJAX-запрос какому-нибудь http-хэндлеру или веб-сервису,
> который возвращает нечто, что можно тут же применить к
> документу. Через клиентский скрипт.
> 2. POST-запрос через submit или АЯКС, опять же. Сервер в
> случае необходимости может отредиректить пользователя на
> нужную страницу после получения и обработки запроса (как
> в случае логина, например).
>
правильно. Вот теперь такая ситуация:
1. Есть система, в которой пользователю надо авторизоваться.
2. В зависимости от прав пользователя контент на странице может быть разный (например, добавляются дополнительные кнопки).
В этом случае имеем 2 стриницы:
1. С окошком Login-Pwd
2. Основная страница.
На странице авторизации пользователь вводит логин-пароль, это через post-запрос попадает на сервер. Сервер это дело переваривает и в случае успешной авторизации у нас есть 2 пути:
Путь 1. Сервер полностью генерит всю основную страницу целиком, в зависимости от прав пользователя.
Путь 2. Сервер переадресует пользователя на основную страницу, добавив параметром URL его (пользователя) id.
На основной странице происходит то, что я выше в примере привёл, только вместо тупого вывода в innerHTML организуется AJAX-запрос с post (или get, лично через post делаю) - параметром UserID. Который был взят из URL.
И вот уже только тогда сервер обрабатывает права пользователя с данным id и высылает ответ, в котором сформирован только набор кнопок, а не вся страница целиком.
clickmaker (2008-12-11 13:38:00) [13]так это же у тебя клиентский скрипт.
Если ты это имел в виду под "передать странице", то да
На самом деле, при передаче данных, которые не влезают в урл (или которые не желательно туда пихать), есть 2 способа:
1. AJAX-запрос какому-нибудь http-хэндлеру или веб-сервису, который возвращает нечто, что можно тут же применить к документу. Через клиентский скрипт.
2. POST-запрос через submit или АЯКС, опять же. Сервер в случае необходимости может отредиректить пользователя на нужную страницу после получения и обработки запроса (как в случае логина, например).
Ega23 (2008-12-11 13:36:00) [14]
> GET - это то, что через переменные окружения пришло
Точнее, через переменную окружения 'QUERY_STRING'
Ega23 (2008-12-11 13:32:00) [15]
> Значит "передать странице" = "передать серверу"
Вот насколько я понимаю, это не совсем так. Точнее - не обязательно. В случае, когда идёт пост-обработка данных на странице уже после получения контента.
Пример:
А, ччёрт, html-тэги поди тут не пропустит. Ну да ладно.
Короче, внутри body есть только один div с id="mydiv"
Дальше в head добавляем такой скрипт:
function GetLocationParam(name) {
var params = window.location.search.substr(1).split("&");
for(i=0;i
Anatoly Podgoretsky (2008-12-11 13:31:00) [16]> Ega23 (11.12.2008 13:19:18) [18]
Ты неправ.
Anatoly Podgoretsky (2008-12-11 13:31:00) [17]> Ega23 (11.12.2008 13:19:18) [18]
Ты неправ.
clickmaker (2008-12-11 13:23:00) [18]> не странице передаёшь, а серверу
так... теперь я не понял.
Какая разница? страница формируется на сервере. Значит "передать странице" = "передать серверу"
Поправьте меня, если я не прав
Ega23 (2008-12-11 13:19:00) [19]
> а как передаются всякие логины-пароли? не через Post же
Ну ты же это дело не страницепередаёшь, а серверу.
А странице, насколько я понимаю, какую-то информацию можно передать только:
1. Внутри контента респонса на http-reqwest
2. В виде куки.
3. В строке URL.
А так, с точки зрения CGI или FastCGI, GET - это то, что через переменные окружения пришло, POST - то что в StdIn было запихнуто.
Поправьте меня, если я не прав.
clickmaker (2008-12-11 13:07:00) [20]> не через Post же
то есть, не через Get же )
вообще, информацию, которая представляет некоторую ценность (коды, пароли всякие) в открытом виде через урл лучше не передавать