LINUX.ORG.RU

JQuery 1.3

 ,


0

0

Вышла новая версия замечательного JS-фреймворка, использующегося на множестве сайтов в интернет.

Среди основных особенностей данной версии разработчики отмечают прежде всего бОльшую скорость работы (заявлено улучшение на 49% по сравнению с предыдущей версией). Попутно, разумеется, появилось множество новых функций и селекторов, правда, к сожалению, некоторые были объявлены устаревшими, например больше нельзя писать $('имя[@атрибут]'), теперь знак @ надо опускать.

Разработчики надеются, что переход на новую версию не будет болезненным :)

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

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

В общем качаем, обновляем, читаем.

>>> Подробности

Ответ на: комментарий от Karapuz

>Толстый? Тролль? Еще раз, для тех, до кого долго доходит.

До тебя еще не дошло что ты тролль? Попробуй пролезть через 14" монитор, в моем ты застревашь.

wfrr ★★☆
()
Ответ на: комментарий от kto_tama

Наоборот. Обычное дело, говорит о том, что изначально был изьян в архитектуре и первые версии писались ПТУшниками по ночам после основной работы. Соответственно в коде баг на баге. И теперь с выходом каждого нового билда баги будут вычищать и радостно сообщать о кратных приростах производительности

Karapuz ★★★★★
()
Ответ на: комментарий от Karapuz

Ничего другого не знаешь? Берёшь свежевыпущенную под LGPL Qt и вперёд.

Кстати, а PyQt под LGPL будет?

anonymous
()
Ответ на: комментарий от Karapuz

Все так говорят, но ты именно троллишь, можешь залезть на кивипедию и сравнить свои метанации и признаки тролля, совпадает 1 в 1.

wfrr ★★☆
()
Ответ на: комментарий от wfrr

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

Тогда все мечты о масштабируемости отваливаются. :) Какой бы сессия не была при n-ном кол-ве пользователей она станет узким местом. В ресте так - клиент хранит сессию и эффективно кэширует, а сервер stateless. Я думаю, всё уже реализуемо, просто тропинка не протоптана, как следует.

Bohtvaroh ★★★★
()
Ответ на: комментарий от Bohtvaroh

>Какой бы сессия не была при n-ном кол-ве пользователей она станет узким местом.

1024 юзера в 3 часа, это ассоциированный массив с размером ключей 32 килобайта, это чтоли нагрузка? В виде данныз массива будет список ролей пользователя и все.

wfrr ★★☆
()
Ответ на: комментарий от wfrr

Ну это смотря, что в сессии хранить. Если как в java ee в HttpSession пихают чего не попадя, то нифига не 32 килобайта получится. ;-)

Bohtvaroh ★★★★
()
Ответ на: комментарий от Bohtvaroh

>Если как в java ee в HttpSession пихают чего не попадя, то нифига не 32 килобайта получится. ;-)

Этож от разработчиков зависит. некоторые вот соединение к базе раз 20 открывают в обработке одной страницы.

wfrr ★★☆
()
Ответ на: комментарий от wfrr

А еще на форумах частый вопрос как засунуть соединение к базе в сессию.

wfrr ★★☆
()
Ответ на: комментарий от Bohtvaroh

> В ресте так - клиент хранит сессию и эффективно кэширует, а сервер stateless. Я думаю, всё уже реализуемо, просто тропинка не протоптана, как следует.

А я хотел протоптать. Проблема в поисковиках (почти решаемая) и пользователях всяких телефонов/пда/noscript-ов, у которых JS отродясь не работал (т.е. состояние хранить нельзя). Для остальных пользователей - хоть сейчас сделать можно. Но поскольку на "мобильных" пользователей забить нельзя, приходится механизм сессий дублировать и на клиете, и на сервере.

EmStudio
()
Ответ на: комментарий от EmStudio

Имхо проблема в поисковиках только, нормальный человек через мабилу на интернет магазин не полезет.

wfrr ★★☆
()
Ответ на: комментарий от wfrr

Нормальные люди и картинки за смс по 100р не скачивают. Мне же деньги нужны. Акромя того, движок я рисую универсальный, дабы не только магазы делать можно было, но и LOR2.0, а его с телефона было бы приятно почитать.

EmStudio
()
Ответ на: комментарий от wfrr

sitemap + url-обфускатор с данными по документам (ресурсам) + в суффиксах ".htm", не?

Кстати, сессии на сервере все равно делать, ибо злобные хакиры могут поправить запрос и придет БольшойП. Валидацию (100% корректную) без сессий не сделать.

Как вариант - использовать флеш и не рвать соединение с сервером на протяжении всей работы. Но это уже и не http будет.

EmStudio
()
Ответ на: комментарий от wfrr

Можно информацию критичную для поисковиков сразу включать в страницу, а динамически подгружать всё остальное. Как-то так...

Bohtvaroh ★★★★
()
Ответ на: комментарий от EmStudio

> Кстати, сессии на сервере все равно делать, ибо злобные хакиры могут поправить запрос и придет БольшойП. Валидацию (100% корректную) без сессий не сделать.

Дык ведь аутентификация на что или о чём речь?

Bohtvaroh ★★★★
()
Ответ на: комментарий от EmStudio

>sitemap + url-обфускатор с данными по документам (ресурсам) + в суффиксах ".htm", не?

ИМХО если в суффиксах будет x*u с точки зрения поисковика ничего не поменяется, заморочка в том что если…. а блин лучше почитай http://citkit.ru/articles/491/

wfrr ★★☆
()
Ответ на: комментарий от Bohtvaroh

Ну как бы не следует доверять данным с клиентской стороны, ибо все легко подделывается/роботизируется. Все данные надо тщательно проверять, а сделать мы это можем только в том случае, если ожидаем от клиента что-то конкретное.

> Дык ведь аутентификация

Кстати, какая? www-auth с клиента? Отдельный сервис авторизации на мемкешде? Или все равно придем к каким-то сессии-подобным костылям.

EmStudio
()
Ответ на: комментарий от wfrr

> Это в каждом аджакс-запросе слать пароль и имя?

Нееееее...

Сорри, я в этом разделе не силён, но вот открыл Http: The definitive Guide - там вижу: Client identification, Basic, Digest authentication и пр.

Bohtvaroh ★★★★
()
Ответ на: комментарий от Bohtvaroh

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

wfrr ★★☆
()
Ответ на: комментарий от wfrr

> Не, сессия позволяет легко аутентифицироваться и сохранять это состояние всю дорогу, это пока я не вижу чем заменить.

Так тут сессия в принципе не причём, просто в каждом запросе клиента отсылается установленная ему кука, что-то подобное и можно изобразить. Но вроде существующие методы аутентификации должны нормально работать и так...

Bohtvaroh ★★★★
()
Ответ на: комментарий от wfrr

Так в чем проблема? Пришел запрос GET /ustanovka-kondicionerov-s-molotkom-i-vodkoy.html, обфускатор разобрал до viewmodel=statictext&id=8374&state=98734 (да, минисессия), после чего скармливаем контроллеру по отображению для печати - их поисковики нормально хавают. В чем проблема?

> а блин лучше почитай

Много буков, все ниасилил.

EmStudio
()
Ответ на: комментарий от EmStudio

> Ага, а еще с этой штукой очень прикольно logout на сайте делать.

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

Bohtvaroh ★★★★
()
Ответ на: комментарий от Bohtvaroh

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

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

EmStudio
()
Ответ на: комментарий от Bohtvaroh

> Тут дело в том, что куки не труЪ исходя из принципов REST.

Зато как раз предназначены для хранения сессий на клиенте :D

EmStudio
()
Ответ на: комментарий от EmStudio

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

Так ведь закрыть таб - аутентификация (digest) стухнет.

Bohtvaroh ★★★★
()
Ответ на: комментарий от Bohtvaroh

Нафга нужны принцыпы которые усложняют жизнь? Да у них есть полезные вещи как идеология stateless, но стоит подходить без фанатизма.

wfrr ★★☆
()
Ответ на: комментарий от wfrr

в ejb3 они кстати тоже видимо курнули этойе травы и придумали stateless бины (на которых можно писать вебсервисы для тагания ажаксом), однако в 3.1 трава кончилась и они поняли что одними stateless все не решить.

wfrr ★★☆
()
Ответ на: комментарий от EmStudio

> Зато как раз предназначены для хранения сессий на клиенте :D

А толку, ну а если рефрешить страницу не надо, то зачем вообще в них что-то хранить? :)

Bohtvaroh ★★★★
()
Ответ на: комментарий от wfrr

> в ejb3 они кстати тоже видимо курнули этойе травы и придумали stateless бины

stateless session bean там испокон веков, или я чего-то недопонял?

Bohtvaroh ★★★★
()
Ответ на: комментарий от Bohtvaroh

да, это звоночек что мне пора спать.

wfrr ★★☆
()
Ответ на: комментарий от Bohtvaroh

>> Зато как раз предназначены для хранения сессий на клиенте :D

> А толку, ну а если рефрешить страницу не надо, то зачем вообще в них что-то хранить? :)


В общем как по мне, для хранения состояния на клиенте предназначен new Object(), ведь состояние это не то, что должно отправляться в каждом http запросе на сервер, как это происходит с куками, так?

В общем вот из Филдинга:

6.3.4.2 Cookies
An example of where an inappropriate extension has been made to the protocol to support
features that contradict the desired properties of the generic interface is the introduction of
site-wide state information in the form of HTTP cookies [73]. Cookie interaction fails to
match REST’s model of application state, often resulting in confusion for the typical
browser application.
An HTTP cookie is opaque data that can be assigned by the origin server to a user
agent by including it within a Set-Cookie response header field, with the intention being
that the user agent should include the same cookie on all future requests to that server until
it is replaced or expires. Such cookies typically contain an array of user-specific
configuration choices, or a token to be matched against the server’s database on future
requests. The problem is that a cookie is defined as being attached to any future requests
for a given set of resource identifiers, usually encompassing an entire site, rather than
being associated with the particular application state (the set of currently rendered
representations) on the browser. When the browser’s history functionality (the “Back”
button) is subsequently used to back-up to a view prior to that reflected by the cookie, the
browser’s application state no longer matches the stored state represented within the
cookie. Therefore, the next request sent to the same server will contain a cookie that
misrepresents the current application context, leading to confusion on both sides.
Cookies also violate REST because they allow data to be passed without sufficiently
identifying its semantics, thus becoming a concern for both security and privacy. The
combination of cookies with the Referer [sic] header field makes it possible to track a user
as they browse between sites.
As a result, cookie-based applications on the Web will never be reliable. The same
functionality should have been accomplished via anonymous authentication and true
client-side state. A state mechanism that involves preferences can be more efficiently
implemented using judicious use of context-setting URI rather than cookies, where
judicious means one URI per state rather than an unbounded number of URI due to the
embedding of a user-id. Likewise, the use of cookies to identify a user-specific “shopping
basket” within a server-side database could be more efficiently implemented by defining
the semantics of shopping items within the hypermedia data formats, allowing the user
agent to select and store those items within their own client-side shopping basket,
complete with a URI to be used for check-out when the client is ready to purchase.

Bohtvaroh ★★★★
()
Ответ на: комментарий от wfrr

> перевод которой можно найти на весьма авторитетном сайте http://www.ibm.com/developerworks/

Все, дальше читать?

> в тот момент, когда Вася забил поле минимальной разрешенной длины, скажем, “Пар”, на сервер подается единственный http-запрос, в ответ на который сервер возвращает все возможные варианты с таким началом.

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

> Кроме того, корректность вводимых данных нужно проверять не “быстро - потому, что асинхронно” на сервере, а на два порядка быстрее локальным java-скриптом

В js уже можно вызывать libastral для проверки дублей/ключей на сервере? Не знал...

Если говорить о второй проблеме со ссылками, то именно такое решение я и предлагал, ибо оно нужно не только для поисковиков, но и для "мобильних", у которых нету скриптов.

Ничего нового для себя не открыл.

EmStudio
()
Ответ на: комментарий от Bohtvaroh

Конечно, при каждом запросе отправлять не обязательно, а хранить то ты где это будешь? Ведь надо еще адресную строчку менять переодически, дабы на текущий state можно было сослаться.

Кстати, особенно фигово, когда на страничке можно наоткрывать кучу виджетов и на них надо дать ссылку. Тогда начинаются извращения с якорями :(

EmStudio
()
Ответ на: комментарий от wfrr

Не бойся, на ажакс-запросы будет отвечать высокопроизводительный демон на перле. Фронт-энд вообще в виде модуля к lighttpd будет. PHP ты там не увидишь, совсем. Я сам его не люблю. Вместо него будет мое собственное CPAS (Cool Perl Application Server), в нем нет ничего страшного. Где же ты пых узрел, о остроглазый?

EmStudio
()
Ответ на: комментарий от EmStudio

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

А где хранятся настройки и предпочтения юзера? В базе, как обычно. Просто при аутентификации выгружаем их на клиента :)

> Ведь надо еще адресную строчку менять переодически, дабы на текущий state можно было сослаться.

А зачем её менять? Адресная строчка должна чётко идентифицировать концепцию - ресурс, остальное - настройки юзера, про них выше. :)

> Кстати, особенно фигово, когда на страничке можно наоткрывать кучу виджетов и на них надо дать ссылку. Тогда начинаются извращения с якорями :(

Я пока с таким не сталкивался, ничего не скажу.

Bohtvaroh ★★★★
()
Ответ на: комментарий от Bohtvaroh

>> Ведь надо еще адресную строчку менять переодически, дабы на текущий state можно было сослаться.

> А зачем её менять? Адресная строчка должна чётко идентифицировать концепцию - ресурс, остальное - настройки юзера, про них выше. :)

А понял, при переходе между ресурсами наверное придётся делать рефреш, тут надо подумать и всё решится. :D

Bohtvaroh ★★★★
()
Ответ на: комментарий от EmStudio

Кодить на пыхе ты можешь и используя яву, это просто болезнь такая, не обращай внимания, просто лечись.

wfrr ★★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.