Ну если немного углубиться в клиент-серверную технологию в основе http то можно увидеть, что никакой потенциальной неточности на самом деле не произойдёт. Второй клик будет просто проигнорирован, поскольку первый уже переключил флаг. С другой стороны поддерживать адекватное состояние флагов на всех копиях страниц слишком дорого и потому эти состояния обновляются лишь при любом ручном запросе (включая ajax при отправке комментария).
На мой взгляд это положение вещей максимально разумно в сложившейся ситуации.
Не "со стороны", а "по определению". Как "вода мокрая".
Если учесть, что мнений может быть более одного (а вы хорошо видите это здесь), то самым разумным решением будет (и так есть) позволить пользователям самим настраивать так как им удобно. А вот спорить между собой по этому поводу можно только не осознавая, что there is no limits for perfection и никто не является окончательно оптимальным, что путей всегда больше, чем один!
Будет, но в том списке нет ни Java ни C++ =)
Попробуйте повыбирать между интерпретацией функций и интерпретацией классов... Конечно без определённого опыта в извращениях выбор сделать трудно. =)
Писать в php нужно как можно проще. Теоретически это ближе к процедурному подходу, но конечно же при определённом уровне "фантазии" испортить можно любое преимущество. =)
Работать со своими кошельками можно из FF очень давно, но речь не о том!
Страница покупки товара в магазине через WM не имеет отношения к плагинам для FF и, к сожалению, её ошибка не исправлена (и не лечится никакими плагинами) нужно покупать именно через IE
=(
Я считаю оптимальным для себя использование оконного интерфейса где окна браузера развёрнуты не на весь экран, что позволяет контролировать взглядом и другие приложения. лишние колонки мне в этом не нужны, а горизонтальная полоска с табами и прокруткой меня вполне устраивает.
PS повторяю, не стоит считать свой вкус объективным он по определению субъективен. Я по прежнему говорю лишь о себе.
В php очень не хватает компиляции. Пока он является пошагово интерпретируемым, ООП в нём не будет иметь ничего общего с оптимальной производительностью, как и многие варианты автоматизации в нём слишком дороги по ресурсам. =(
Искренне надёюсь, что его весьма неплохой инструментарий получит надёжную базу в виде производительного прекомпилирующего ядра.
За всех говорить не буду, но мне не удобно пользоваться боковыми панелями ни для табов, ни для закладок, ни для истории. Может и вам лучше говорить только о себе, и не претендовать на объективность в споре о вкусах?
Возможно вам подойдёт наш комплексный подход к автоматизации
1. наши сервлеты/cgi обрабатывают запросы if-modified-since (и прочие заголовки связанные с кешированием) максимально раньше любой другой работы по построению страницы.
2. между веб-сервером и клиентом стоит squid в режиме акселерации, который обсуживает из кеша иногда и до 90% всех запросов.
Эта схема опробована на ~100тыс запросов в сутки.
Если вы ещё не определились в платформе программирования, то присмотритесь к Parser весьма неплохая альтернатива php
PS разумеется всё это реализуемо лишь при наличии собственного (dedicated/vds) сервера, поскольку мало кто из провайдеров вобще даёт использовать java, parser или ставят кеширующие акселераторы.
В статике держит, а в динамическом режиме нет и это не удивительно бесплатная версия основывается на файлах а не на sql и потому не годится для больших нагрузок. Там конечно несложно перевести транзакции на базу, но в том числе и благодаря этому решили с ним не связываться стоимость доработки показалась не очень удобной.
честно говоря, из этой статьи я так и не понял, чем XML Sapiens лучше XSLT
Тем же, чем фреймворк лучше библиотеки. (так оно и есть)
С моей стороны было некорректно сравнивать подход "XML + XSLT" с XML Sapiens, поскольку это не равнозначные вещи. XML Sapiens позволяет ускорить разработку сайтов за счёт унификации логики и представления, а "XML + XSLT" лишь конечная обработка данных выданных каким-то движком.
Простая "автоматизация дизайна" выполняется с помощью XSLT, более сложные вещи лучше перекладывать на сервер.
Все известные мне примеры выгрузки XSL к клиенту связаны с автоматизацией, а не с www. Врядли кто-то из разработчиков web рискует парсить XSLT на стороне клиента (моя команда в частности делает XSL-преобразование именно на стороне сервера с помощью библиотеки Sablotron)
Зачем здесь изобретать еще один велосипед, который лишь повторяет уже имеющиеся инструменты?
Поверьте, этот фреймворк имеет определённые преимущества перед многими известными, так что он не зря "коптит небо". =)
А на счет клиентской стороны... Opera не поддерживает XML+XSLT (или последние версии уже поддерживают?), что значительно ограничивает область применения такого подхода.
IE поддерживает и этого пока достаточно. =) Но, как я уже сказал, пока мало кто рискует делать столь революционные шаги отдавать контент в настоящем, семантическом XML (а жаль).
Сталкивался с CMS Sapid (бесплатной на основе XML Sapiens). Очень понравилось, но пока схема XML + XSLT мой процесс устраивает больше как минимум из-за большей простоты понимания.
PS: XSLT это конечно не язык программирования в чистом виде, но его точно не следует путать с CSS. XSLT это язык преобразований из XML во что угодно от HTML и RSS до TeX и PDF. Главное ведь не возможность слепой конвертации, а управляемая конвертация один и тот же xml документа может быть преобразован через XSLT как в семантический XHTML так и в жутко запутанный табличный HTML 3.1 вам решать.
Это не вся правда о XSLT =)
Вы же не ратуете за избавление от javascript в пользу серверного решения?
XSLT может отрабатывать НА СТОРОНЕ КЛИЕНТА. Например можно делать фильтрацию или сортировку таблиц без обращения к серверу и javascript.
С другой стороны даже при использовании XSLT на стороне сервера он великолепно служит для разделения кода и дизайна. Только нормальный дизайн всёже имеет собственную логику в каком-то дизайне анонс новости должен показывать первые 200 знаков, а в каком-то ограничиваться на краю слова, где-то дату нужно выводить в английском формате, а где-то словами и вместе со временем. Удобно автоматизировать дизайн имея в своём распоряжении циклы и ветвления...
Такой вариант внесения программных фишек в дизайн давно зарекомендовал себя и используется в том же Smarty или Mason, но XSLT имеет ряд серьёзных преимуществ перед ними может работать не только в php/perl но и с любым xml, сгенерированным хоть на C++. Опять же сама библиотека (например Sablotron) бинарна, что серьёзно увеличивает производительность движка шаблонов даже на php.
На мой взгляд это положение вещей максимально разумно в сложившейся ситуации.
Если учесть, что мнений может быть более одного (а вы хорошо видите это здесь), то самым разумным решением будет (и так есть) позволить пользователям самим настраивать так как им удобно. А вот спорить между собой по этому поводу можно только не осознавая, что there is no limits for perfection и никто не является окончательно оптимальным, что путей всегда больше, чем один!
Может хватит спорить о вкусах?
Попробуйте повыбирать между интерпретацией функций и интерпретацией классов... Конечно без определённого опыта в извращениях выбор сделать трудно. =)
Страница покупки товара в магазине через WM не имеет отношения к плагинам для FF и, к сожалению, её ошибка не исправлена (и не лечится никакими плагинами) нужно покупать именно через IE
=(
PS повторяю, не стоит считать свой вкус объективным он по определению субъективен. Я по прежнему говорю лишь о себе.
Искренне надёюсь, что его весьма неплохой инструментарий получит надёжную базу в виде производительного прекомпилирующего ядра.
1. наши сервлеты/cgi обрабатывают запросы if-modified-since (и прочие заголовки связанные с кешированием) максимально раньше любой другой работы по построению страницы.
2. между веб-сервером и клиентом стоит squid в режиме акселерации, который обсуживает из кеша иногда и до 90% всех запросов.
Эта схема опробована на ~100тыс запросов в сутки.
Если вы ещё не определились в платформе программирования, то присмотритесь к Parser весьма неплохая альтернатива php
PS разумеется всё это реализуемо лишь при наличии собственного (dedicated/vds) сервера, поскольку мало кто из провайдеров вобще даёт использовать java, parser или ставят кеширующие акселераторы.
Сейчас используем собственную разработку такого плана, но до коммерческого уровня она ещё не доведена (и пока этого нет в планах).
Тем же, чем фреймворк лучше библиотеки. (так оно и есть)
С моей стороны было некорректно сравнивать подход "XML + XSLT" с XML Sapiens, поскольку это не равнозначные вещи. XML Sapiens позволяет ускорить разработку сайтов за счёт унификации логики и представления, а "XML + XSLT" лишь конечная обработка данных выданных каким-то движком.
Все известные мне примеры выгрузки XSL к клиенту связаны с автоматизацией, а не с www. Врядли кто-то из разработчиков web рискует парсить XSLT на стороне клиента (моя команда в частности делает XSL-преобразование именно на стороне сервера с помощью библиотеки Sablotron)
Поверьте, этот фреймворк имеет определённые преимущества перед многими известными, так что он не зря "коптит небо". =)
IE поддерживает и этого пока достаточно. =) Но, как я уже сказал, пока мало кто рискует делать столь революционные шаги отдавать контент в настоящем, семантическом XML (а жаль).
Вы же не ратуете за избавление от javascript в пользу серверного решения?
XSLT может отрабатывать НА СТОРОНЕ КЛИЕНТА. Например можно делать фильтрацию или сортировку таблиц без обращения к серверу и javascript.
С другой стороны даже при использовании XSLT на стороне сервера он великолепно служит для разделения кода и дизайна. Только нормальный дизайн всёже имеет собственную логику в каком-то дизайне анонс новости должен показывать первые 200 знаков, а в каком-то ограничиваться на краю слова, где-то дату нужно выводить в английском формате, а где-то словами и вместе со временем. Удобно автоматизировать дизайн имея в своём распоряжении циклы и ветвления...
Такой вариант внесения программных фишек в дизайн давно зарекомендовал себя и используется в том же Smarty или Mason, но XSLT имеет ряд серьёзных преимуществ перед ними может работать не только в php/perl но и с любым xml, сгенерированным хоть на C++. Опять же сама библиотека (например Sablotron) бинарна, что серьёзно увеличивает производительность движка шаблонов даже на php.