seaside
victor metelitsa
пользоваться для моих приложений. Вот, например, ситуация: я ввожу номер
рейса XXX и дату DD.MM.YYYY (для сервлета это
http://myhost/servlet/MyServlet?pageType=flight&flightNo=XXX&flightDate=DD.MM.YYYY,
для seaside-приложения
http://myhost/seaside/xxxx?_g=xxxxxxx&_k=yyyyyyyyyyy),
и получаю список билетов, причем на странице будет список ссылок вида
http://myhost/servlet/MyServlet?pageType=ticket&ticketNo=XXXXXXXXXX
или для seaside http://myhost/seaside/xxxx?_g=xxxxxxx&_k=zzzzzzzzzzz
В случае сервлетов я могу скопировать ссылку и отослать по почте
пользователю XXX. Она будет действительна всегда, пока в базе есть
данный билет и приложение не слишком поменялось. У пользователя XXX
будет свой сеанс (мой сеансовый ключ ему передан не был), и если у него
нет прав, то он ничего по билету не увидит.
В случае же Seaside, во-первых, ссылка будет действительна, пока не
истечет время моего сеанса (что интересно, в учебниках, которые я видел,
вопрос времени жизни сеанса и что произойдет после его истечения,
игнорируется), а во-вторых, поскольку юзер XXX получит мой сеансовый
ключ, который по непонятным мне причинам закодирован в URL, а не в
cookie, он автоматически получит все мои права. Если же проверять еще и
IP браузера, во-первых, непонятно, где его взять, и, во-вторых, если мы
оба работаем через proxy, это может не помочь.
Также, мне очень удобно пользоваться URL типа
http://myhost/servlet/MyServlet?pageType=ticket&ticketNo=XXXXXXXXXX
правя эту строку прямо в браузере (предположим, мне понадобилось
посмотреть билет YYYYYYYYYY), тогда как с
http://myhost/seaside/xxxx?_g=xxxxxxx&_k=zzzzzzzzzzz непонятно, что
можно делать.
Допустим, что есть способ узнать значение ticketNo=XXXXXXXXXX из
Seaside. Тогда возникает следующий вопрос: как закодировать список
билетов с URL? Надо выбирать одно из двух: либо добавлять в URL
сеансовый ключ, и тогда его нельзя посылать по почте по вышеизложенным
причинам, либо не добавлять, но тогда придется создавать новые сеансы
(и вводить имя и пароль) каждому пользователю для каждого открываемого
билета! Если сеансовый ключ передавался бы в cookie, такой проблемы бы
не было. Впрочем, тут есть еще и Continuation Key, который испортит всю
малину.
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Andrei N. Sobchuck
vm> Несмотря на всю "красоту" Seaside, я совершенно не понимаю, как им
vm> пользоваться для моих приложений. Вот, например, ситуация: я ввожу номер
vm> рейса XXX и дату DD.MM.YYYY (для сервлета это
vm> http://myhost/servlet/MyServlet?pageType=flight&flightNo=XXX&flightDate=DD.MM.YYYY,
vm> для seaside-приложения
vm> http://myhost/seaside/xxxx?_g=xxxxxxx&_k=yyyyyyyyyyy),
vm> и получаю список билетов, причем на странице будет список ссылок вида
vm> http://myhost/servlet/MyServlet?pageType=ticket&ticketNo=XXXXXXXXXX
vm> или для seaside http://myhost/seaside/xxxx?_g=xxxxxxx&_k=zzzzzzzzzzz
В seaside есть механизм для работы с "постоянными" урлами. Хотя и не
полностью прозрачный для пользователя.
Пример: http://squeak.saltypickle.com/LiveWeb/
Что нужно сделать:
У какого либо видимого компонента реализовать метод #updateUrl:
Типа так:
updateUrl: aUrl
aUrl addParameter: 'pageType' value: 'flight'.
aUrl addParameter: 'flightNo' value: '123'.
Я так понимаю можно использовать:
#addParameter:, #addParameter:value:, #addToPath:, #fragment:
Эти параметры будут добавлены к параметру сессии/продолжения.
Потом нужно создать подкласс от WAMain, зарегистрировать его
в конфигураторе и переопределить метод #start:
Этот метод будет вызван при инициализации сессии.
Параметром для #start: будет экземпляр WARequest.
Из этого запроса можно вытащить параметры и проинициализировать
приложение. Например:
start: aRequest
| aComponent |
aComponent := WACounter new.
aComponent count: (aRequest at: 'count').
"метода #count: там нет, но это же пример"
(WARenderLoop new root: aComponent) start: aRequest
В поле броузера естесвенно будет видимы сессия и продолжение (если
сессию еще можно в куки перенести, то продолжение никак).
Тут я не силён, но может эти параметры можно JavaScriptom обрезать из
поля броузера и показывать текущий "красивый" URL?
--
Andrei N.Sobchuck
JabberID: and...@jabber.ru. ICQ UIN: 46466235.
victor metelitsa
[...]
> В seaside есть механизм для работы с "постоянными" урлами. Хотя и не
> полностью прозрачный для пользователя.
>
> Пример: http://squeak.saltypickle.com/LiveWeb/
>
Что-то непонятное для сквика (тоже непонятного).
> Что нужно сделать:
> У какого либо видимого компонента реализовать метод #updateUrl:
> Типа так:
>
> updateUrl: aUrl
> aUrl addParameter: 'pageType' value: 'flight'.
> aUrl addParameter: 'flightNo' value: '123'.
>
> Я так понимаю можно использовать:
> #addParameter:, #addParameter:value:, #addToPath:, #fragment:
>
Добавить-то можно, зато насчет убрать...
К тому же мне нужен еще не существующий на данный момент метод
anchorWithAction: actionBlock parameters: parameters text: aString
с использованием наподобие
ticketNoCollection := #('1234567890' '0987654321').
ticketNoCollection do: [:eachNo|
(parameters := Dictionary new)
at: 'pageType' put: 'showTicket';
at: 'ticketNo' put: eachNo.
html
anchorWithAction: [self showTicket: eachNo ]
parameters: parameters
text: 'билет # ', eachNo
].
И чтобы в anchor'е не было никаких сеансовых ключей. И, возможно, чтобы
открывалось обязательно в новом окне (в некоторых случаях удобнее именно
так).
Кстати, в VW 7.3 у меня не работали метки (то, что в Seaside обозвали
фрагментами;
http://myhost/servlet/MyClass?param=xxx;param=yyy#fragment); VW 7.3.1 не
проверял пока.
> Эти параметры будут добавлены к параметру сессии/продолжения.
> Потом нужно создать подкласс от WAMain, зарегистрировать его
> в конфигураторе и переопределить метод #start:
> Этот метод будет вызван при инициализации сессии.
> Параметром для #start: будет экземпляр WARequest.
> Из этого запроса можно вытащить параметры и проинициализировать
> приложение. Например:
>
> start: aRequest
> | aComponent |
> aComponent := WACounter new.
> aComponent count: (aRequest at: 'count').
> "метода #count: там нет, но это же пример"
> (WARenderLoop new root: aComponent) start: aRequest
>
Ну... это ведь нужно не только при старте...
> В поле броузера естесвенно будет видимы сессия и продолжение (если
> сессию еще можно в куки перенести, то продолжение никак).
> Тут я не силён, но может эти параметры можно JavaScriptom обрезать из
> поля броузера и показывать текущий "красивый" URL?
Что-то в этом духе пытались делать для фишинга, и не раз получалось.
Сайт, выдающий себя за другой сайт, с целью воровства паролей. Очевидно,
с пропатченным IE или Мозиллой фокус пройти уже не должен.
Сеансовый ключ _обязан_ быть в куке. "Продолженческий", очевидно, нет.
Прикладнуха обязана опознавать ситуации, когда дополнительные параметры
указаны, а "продолженческий" ключ не валиден.
Увидел странную привычку Seaside (из комплекта 7.1.3; в цинкомовском
репозитарии дикая смесь пакетов и бандлов, имена которых не совпадают с
тем, что на CD.) - чуть что, говорить, что время сеанса истекло, и
делать редирект на совершенно пустую страницу. Сайты на вебе тоже далеко
не безглючны.
Короче, получается, либо к AIDA'е внимательно присмотреться (на первый
взгляд она мне совсем не понравилась, но может, на второй...?), либо так
и оставаться на сервлетах - тоже та еще гадость...
Andrei N. Sobchuck
>> В seaside есть механизм для работы с "постоянными" урлами. Хотя и не
>> полностью прозрачный для пользователя.
>>
>> Пример: http://squeak.saltypickle.com/LiveWeb/
>>
vm> Что-то непонятное для сквика (тоже непонятного).
Это как пример постоянного URLа.
vm> К тому же мне нужен еще не существующий на данный момент метод
vm> anchorWithAction: actionBlock parameters: parameters text: aString
А, понял. чесно говоря не знаю. Но думаю, что добавить метод с таким
поведением сложности нет.
vm> И чтобы в anchor'е не было никаких сеансовых ключей. И, возможно, чтобы
Ну, уж замаскировать UEL на странице при помощи JavaScript точно можно.
vm> открывалось обязательно в новом окне (в некоторых случаях удобнее именно
vm> так).
Стандартный html. тут вообще ничего менять не нужно.
>> Параметром для #start: будет экземпляр WARequest.
>> Из этого запроса можно вытащить параметры и проинициализировать
vm> Ну... это ведь нужно не только при старте...
Так после старта сессии у тебя заработает "обыкновенная" "потоковая" логика.
vm> Сеансовый ключ _обязан_ быть в куке. "Продолженческий", очевидно, нет.
Почему обязан? какая польза?
vm> Прикладнуха обязана опознавать ситуации, когда дополнительные параметры
vm> указаны, а "продолженческий" ключ не валиден.
session expired :) не разбирался как, но реакцию на это тоже добавить можно.
vm> Увидел странную привычку Seaside (из комплекта 7.1.3; в цинкомовском
vm> репозитарии дикая смесь пакетов и бандлов, имена которых не совпадают с
Грузиш пакет SeasideForWebToolkit. Остальное всё само грузится.
Причина столь разительного отличия структуры в репозитории и в дистрибутиве
удивляет и меня, но не пугает :)
vm> тем, что на CD.) - чуть что, говорить, что время сеанса истекло, и
за причину не скажу. знаю только, что помимо устаревания сессии
там есть еще ограничение на кол-во "шагов". То есть хранится N последних
шагов, а всё что раньше - expired. То есть кнопочку назад в проводнике
не сильно можно тыкать. Где крутить - еще не интересовался.
vm> делать редирект на совершенно пустую страницу. Сайты на вебе тоже далеко
vm> не безглючны.
например?
vm> Короче, получается, либо к AIDA'е внимательно присмотреться (на первый
vm> взгляд она мне совсем не понравилась, но может, на второй...?), либо так
vm> и оставаться на сервлетах - тоже та еще гадость...
Посмотри SimpleWeb http://tinyurl.com/8nld3
Второй вариант - подумать над совмещением двух подходов. Seaside для
всяких мастеров, и сервлеты (или что угодно) для вывода простых интерфейсов.
--
Andrei N.Sobchuck
JabberID: and...@jabber.ru. ICQ UIN: 46466235.
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
victor metelitsa
[...]
>
>
> Ну, уж замаскировать UEL на странице при помощи JavaScript точно можно.
>
Нужна не маскировка, а возможность скопировать URL и передать другому
человеку.
> vm> открывалось обязательно в новом окне (в некоторых случаях удобнее именно
> vm> так).
>
> Стандартный html. тут вообще ничего менять не нужно.
>
Тогда не нужен и Seaside?
>
>>>Параметром для #start: будет экземпляр WARequest.
>>>Из этого запроса можно вытащить параметры и проинициализировать
>
> vm> Ну... это ведь нужно не только при старте...
>
> Так после старта сессии у тебя заработает "обыкновенная" "потоковая" логика.
>
Положим, я получил письмо с
http://myhost/servlet/MyServlet?pageType=ticket&ticketNo=XXXXXXXXXX
http://myhost/servlet/MyServlet?pageType=ticket&ticketNo=YYYYYYYYYY
http://myhost/servlet/MyServlet?pageType=ticket&ticketNo=ZZZZZZZZZZ
и открыл каждую страницу. Почему я должен три раза начинать новый сеанс
и каждый раз вводить имя и пароль?
> vm> Сеансовый ключ _обязан_ быть в куке. "Продолженческий", очевидно, нет.
>
> Почему обязан? какая польза?
>
Потому что он где-то должен быть, но не в URL, а значит, кука -
единственное место. А почему он не должен быть в URL, я объяснял. Потому
что письма. Кстати, и веб-поисковики тоже. И пример с тремя URL-ами выше.
[...]
> vm> делать редирект на совершенно пустую страницу. Сайты на вебе тоже далеко
> vm> не безглючны.
>
> например?
>
Прямо сейчас уже не скажу, но я видел страницу с отсутствующим содержанием.
> vm> Короче, получается, либо к AIDA'е внимательно присмотреться (на первый
> vm> взгляд она мне совсем не понравилась, но может, на второй...?), либо так
> vm> и оставаться на сервлетах - тоже та еще гадость...
>
> Посмотри SimpleWeb http://tinyurl.com/8nld3
>
> Второй вариант - подумать над совмещением двух подходов. Seaside для
> всяких мастеров, и сервлеты (или что угодно) для вывода простых интерфейсов.
И пятый вариант - написать своё ;-)
--
Andrei N. Sobchuck
>> vm> И чтобы в anchor'е не было никаких сеансовых ключей. И, возможно, чтобы
>> Ну, уж замаскировать UEL на странице при помощи JavaScript точно можно.
vm> человеку.
Я так понимаю оно так и работает. Видиш ты одно. onclick срабатывает другое.
Персонально мне применение JavaScript не по душе, но ради презентабельности...
>> vm> открывалось обязательно в новом окне (в некоторых случаях удобнее именно
>> Стандартный html. тут вообще ничего менять не нужно.
vm> Тогда не нужен и Seaside?
Не понял? Я про <a href="http://...." target="_blank">
>> vm> Ну... это ведь нужно не только при старте...
>> Так после старта сессии у тебя заработает "обыкновенная" "потоковая" логика.
vm> Положим, я получил письмо с
vm> http://myhost/servlet/MyServlet?pageType=ticket&ticketNo=XXXXXXXXXX
vm> http://myhost/servlet/MyServlet?pageType=ticket&ticketNo=YYYYYYYYYY
vm> http://myhost/servlet/MyServlet?pageType=ticket&ticketNo=ZZZZZZZZZZ
vm> и открыл каждую страницу. Почему я должен три раза начинать новый сеанс
vm> и каждый раз вводить имя и пароль?
А понял. Тогда таки нужны куки. См. тот же WARequest.
>> Второй вариант - подумать над совмещением двух подходов. Seaside для
>> всяких мастеров, и сервлеты (или что угодно) для вывода простых интерфейсов.
vm> И пятый вариант - написать своё ;-)
Не уверен. Вариантов то, http не много оставляет :( Как по мне, то "смешанный"
вариант - самое то.
victor metelitsa
> victor metelitsa <v...@cssc.tat.ru> wrote:
>
>>> vm> И чтобы в anchor'е не было никаких сеансовых ключей. И, возможно, чтобы
>>>Ну, уж замаскировать UEL на странице при помощи JavaScript точно можно.
>
> vm> Нужна не маскировка, а возможность скопировать URL и передать другому
> vm> человеку.
>
> Я так понимаю оно так и работает. Видиш ты одно. onclick срабатывает другое.
> Персонально мне применение JavaScript не по душе, но ради презентабельности...
>
А что будет на "Copy link location" (чтобы вклеить в письмо)? А-а-а,
вставить в href без session key, а на on click запускать с session key?
>
>>> vm> открывалось обязательно в новом окне (в некоторых случаях удобнее именно
>>>Стандартный html. тут вообще ничего менять не нужно.
>
> vm> Тогда не нужен и Seaside?
>
> Не понял? Я про <a href="http://...." target="_blank">
>
И я про то же. Такое я и с банальными сервлетами могу, но это не то, что
я хочу.
>>> vm> Ну... это ведь нужно не только при старте...
>>>Так после старта сессии у тебя заработает "обыкновенная" "потоковая" логика.
>
> vm> Положим, я получил письмо с
> vm> http://myhost/servlet/MyServlet?pageType=ticket&ticketNo=XXXXXXXXXX
> vm> http://myhost/servlet/MyServlet?pageType=ticket&ticketNo=YYYYYYYYYY
> vm> http://myhost/servlet/MyServlet?pageType=ticket&ticketNo=ZZZZZZZZZZ
> vm> и открыл каждую страницу. Почему я должен три раза начинать новый сеанс
> vm> и каждый раз вводить имя и пароль?
>
> А понял. Тогда таки нужны куки. См. тот же WARequest.
>
Т.е. есть механизм? Интересно, надо попробовать.
>
>>>Второй вариант - подумать над совмещением двух подходов. Seaside для
>>>всяких мастеров, и сервлеты (или что угодно) для вывода простых интерфейсов.
>
>
> vm> И пятый вариант - написать своё ;-)
>
> Не уверен. Вариантов то, http не много оставляет :( Как по мне, то "смешанный"
> вариант - самое то.
Seaside для меня интересен тем, что не нужно особо заботиться об HTML.
Эти всякие anchorWithAction: actionBlock text: aString и т.п.
callback'и, аналогично с формами. Отвлечься от самого факта
существования HTML, короче (как мы отвлекаемся от существования SQL с
GLORP'ом). Поэтому смешанный подход мне крайне не нравится, как и не
нравится вынужденное обращение к SQL из-за отсутствия (или недоделок) в
GLORP'е ряда важных вещей (а может, я что-то упустил? ну, как вот
сделать аналог SELECT SUBSTR(str,1,2), COUNT(*) FROM ... GROUP BY
SUBSTR(str,1,2)?).
С другой стороны, похоже, мне мешают те самые continuations, которые
считаются главным достоинством Seaside. Подход AIDA'ы "у каждого объекта
есть свой постоянный URL" для меня привлекательнее. Юзабельна ли она для
меня - это вопрос (то, что автор ее использует много лет, еще ни о чем
не говорит).
"Пятый вариант" - сымитировать renderer от Seaside, сделать похожий
протокол, но выполнять внутри сервлетов и не вспоминать о continuations.
Имена/параметры для URL можно давать явно. Но хорошо ли получится?...
victor metelitsa
"латинских" кодировок бывают и другие, и на преобразовании строки с
русскими символами в байтовый массив вылетают ошибки. В том числе там,
где, на первый взгляд, такого быть не может (доступ к файлу HTML без
русских символов) - они конвертят даты в строки, почему-то стандартным
образом (не учитывая часовых поясов), а там появляется пресловутая
непонятно откуда взявшаяся буква "г".
Andrei N. Sobchuck
vm> Копаюсь в Swazoo... Как бывает очень часто, люди забыли, что кроме
vm> "латинских" кодировок бывают и другие, и на преобразовании строки с
vm> русскими символами в байтовый массив вылетают ошибки. В том числе там,
vm> где, на первый взгляд, такого быть не может (доступ к файлу HTML без
vm> русских символов) - они конвертят даты в строки, почему-то стандартным
vm> образом (не учитывая часовых поясов), а там появляется пресловутая
vm> непонятно откуда взявшаяся буква "г".
Хе-хе. Я когда поднимал SmallWiki на VW+Swazoo, то фиксил его на предмет
работы с кирилицей в URL. Если интересно, то найду эти патчи.
На счет дат - не дошел до этого момента.
Andrei N. Sobchuck
vm> А что будет на "Copy link location" (чтобы вклеить в письмо)? А-а-а,
vm> вставить в href без session key, а на on click запускать с session key?
Ага.
>> А понял. Тогда таки нужны куки. См. тот же WARequest.
vm> Т.е. есть механизм? Интересно, надо попробовать.
Да. Там в WARequest содержит всю информацию из запроса. Включая куки.
Его нужно перехватить так, как я указал выше, и сразу создать
нужный компонент, а не компонент ввода пароля.
Всяких механизмов в Seaside куча. Проблема в том, что бы все их изучить ;)
>> Не уверен. Вариантов то, http не много оставляет :( Как по мне, то "смешанный"
>> вариант - самое то.
vm> С другой стороны, похоже, мне мешают те самые continuations, которые
vm> считаются главным достоинством Seaside. Подход AIDA'ы "у каждого объекта
vm> есть свой постоянный URL" для меня привлекательнее. Юзабельна ли она для
vm> меня - это вопрос (то, что автор ее использует много лет, еще ни о чем
vm> не говорит).
Я так понимаю, что это почти сервлеты.
vm> "Пятый вариант" - сымитировать renderer от Seaside, сделать похожий
vm> протокол, но выполнять внутри сервлетов и не вспоминать о continuations.
vm> Имена/параметры для URL можно давать явно. Но хорошо ли получится?...
http://people.squeakfoundation.org/proj/HttpView2/
Или упоминаемый мной SimpleWeb. Увы, документации на SimpleWeb нет вообще.
Но, похоже это то, чего ты хочеш. Генерилка html a-la Seaside плюс
callback-и.