> реализации, как всегда, отличаются в IE и не в IE
разумеется все процессоры разные, но почему ие вдруг ставится особняком? xslt придуман не мелкософтом, но реализован ими раньше всех.
> игнорирование первого xsl:call-template
не наблюдаю такого
> и сложными предикатами
например, какими?
> а иногда — загрузка картинки до трансформации.
иногда? какой картинки? откуда?
> Хром требует отличного от других браузеров xsl:output.
какого?
больно уж они похожи на баги, с которыми было лень разбираться и свалили всё на «причуды браузера»
из того, что я знаю, наиболее сильное отличие от остальных — в процессоре мозиллы и то не такие уж страшные, но про неё тут ни слова почему-то.
> Самым популярным способом диагностирования проблем является комментирование кусков шаблона.
это проблема также и любого препроцессора. будь то yate, bemhtml, stylus или любой другой. понять что происходит по нагенеренному коду может только тот, кто этот препроцессор написал (или хорошо его изучил). для остальных же, это чёрный ящик как и xslt.
> в браузере же приходится сильно исхитряться со стандартными средствами, чтобы как-то нестандартно обработать строки
очень спорный момент, должен ли этим заниматься шаблон. но таки да, за возможность запускать его в любом окружении (а не через виртуальную js-машину) приходится платить невозможностью расширить своими прибамбасами.
> E4X на самом деле не очень удобный
да ладно? одно только «root..descendant» чего стоит. или отсутствие «null pointer exception». по скорости — да, не нативно. но вы же яваскрипт не из-за скорости выбрали.
далее, про тесты. я не нашёл в документации делает ли yate автоматическое экранирование данных (и если да, то решили ли вы проблему формирования json внутри html, где нужно двойное экранирование?). если нет экранирования, то тесты не корректны, синтаксис громоздкий, а XSS близко. от какого и до какого момента замерялась скорость (только трансформация или плюс парсинг данных, парсинг шаблона, формирование дома)? дело в том, что xslt позволяет сразу формировать поддерево целевого документа (а значит сериализация и как следствие экранирование не нужны вообще), а yate генерирует строку, которую потом ещё браузеру придётся парсить.
кроме того в xslt есть интересная особенность — многопроходная трансформация, которая сильно помогает в случае, когда данные могут приходить в разных форматах — первым проходом нормализуем данные, а вторым формируем целевой документ.
а в целом — не плохо, хоть один приличный json шаблонизатор. всё остальное либо императивное, либо как мусташ примитивное.
«Всё правильно, одиночные кавычки согласно RFC 3986 кодируется как %27.»
не правильно. читаем приложение А, где собран формальный синтаксис:
path = path-abempty; begins with "/" or is empty
/ path-absolute; begins with "/" but not "//"
/ path-noscheme; begins with a non-colon segment
/ path-rootless; begins with a segment
/ path-empty; zero characters
упомянутые символы _не требуют_ кодирования процентом в пути, потому что они не могут быть неправильно распознаны (как, например, знак вопроса), хотя и _могут_ быть закодированы, например, в случае, когда нам нужно вставить произвольные данные в произвольное место урла — в этом случае проще воспользоваться одной функцией, которая кодирует все символы имеющие в урле особое значение.
поэтому лучше сравнивать не сырые uri, а нормализованные — тогда никаких петель не будет. «склейщик страниц» тоже наверно не дурак и производит нормализацию ссылок.
nin-jin.github.com/article/article_fiber/article_fiber.doc.xml
работает в мозилле (с типом «application/javascript;version=1.7») и хроме (при включённом «экспериментальном JavaScript»)
осталось дождаться пока генераторы появятся в остальных браузерах
а вот если бы вы не выпендривались, считая себя самыми умными и свои решения самыми оптимальными, а смиренно подняли вопрос в своём же /qa/ как решить эту проблему без издевательств над пользователями, то вам бы подсказали как: #comment_5120574
но нет, гипертрофированное эго, убаюкивающее сознание сказкой «я же профессионал», не позволяет попросить совета у сообщества, ведь «там сидят одни дилетанты, далёкие от наших высоконагруженных проблем»
кстати, не пора бы меня снова забанить? а то я тут опять унижаю вас на вашем собственном сайте и пишу не по понятиям великого и могучего…
«посоны, MVC — это прошлый век, сейчас я покажу вам настоящу, уличную магию!» и показывает всё тот же mvc-треугольник, но с разноцветными стрелочками, который с гордостью называет MOVE
операции, модели, представления… это же функции, структуры и шаблоны знакомые нам с доисторических времён
а вообще, треугольник этот в клиент-серверную архитектуру не вписывается совершенно — отсюда и столько версий «истинного mvc»
программисты всего мира буквально молятся на эту аббревиатуру, устраивая священные войны о том как правильно её толковать, вместо того, чтобы понять один простой и понятный принцип: если что-то меняется одновременно — выдели их в одну группу, минимизировав число точек контакта с остальным кодом.
если тебуется менять одну субд на другую — выдели код общения с ней в отдельный слой и назови его «драйвер базы данных» или даже «объектно-реляционный преобразователь»
если требуется поддержка разных клиентов — выдели код общения с ними в отдельный слой и назови «фронтальный контроллер». для всяких soap-ов и json-rpc большего и не надо.
если требуется менять формат ответа для одних и тех же возвращаемых данных — выдели код, формирующий ответ в отдельный слой и назови его «представление».
если нужно менять правила работы с данными — выдели их в отдельный код и назови его «бизнес логика».
а если всего этого не надо — фигачь всё вместе, но не забывай, что для разных задач есть разные языки более соответствующие языки: языки программирования, языки шаблонов, языки запросов, языки стилизации, языки настройки, языки сопоставления с образом и многие другие.
и не надо спорить о том сколько слоёв должно быть в приложении — 3 или 4. их может потребоваться гораздо больше. и совершенно не важно как их называть, лишь бы было понятно их предназначение.
сложность в том, что нужно настраивать, инклудить. куда удобней иметь какой-нибудь аналог автолоада из пхп. причём автолоада целиком модуля (клиентские скрипты, стили, локали, серверные скрипты, документация, шаблоны).
в иешках проблема с __defineGetter__
а в геттере только eval происходит, но загрузка должна быть произведена заранее асинхронно?
как у него с поддержкой ie9-? во время подгрузки скриптов жизнь в браузере замирает?
я вот остановился на такой схеме: всё приложение делится на набор пакетов, пакеты на модули, в модулях уже скрипты, стили, картинки, шаблоны. сборщик пробегается по ним и «собирает пакеты». шаблоны в одну кучку, стили в другую, скрипты в третюю. при этом статически же определяются зависимости: из шаблонов определяется какие компоненты используются и подключаются одноимённые модули (целиком, со всеми ресурсами и их зависимостями), аналогично разруливаются зависимости между скриптами (используется простое соглашение: $jam.Component — модуль Component из пакета jam). в результате получается на каждый тип файла два варианта — отладочный с пофайловым подключением и релизный со слиянием воедино. есть ещё вариант со сквозной минификацией, когда атомы (http://habrahabr.ru/post/97670/) в шаблонах, стилях и скриптах заменяются на короткие
var Man= Factory( new function( ){
this.name= 'anonymous'
this.init= function( name ){
this.name= name
return this
}
this.scream= function( ){
alert( this.name + '!' )
return this
}
} )
что именно плохо? в отличие от предложенных выше решений тут нет проблем со скроллированием страницы на фоне модального окна, скроллбар страницы затеняется вместе со страницей, а у модального окна свой независимый скроллинг, который тут выполнен внутри окна, чтобы шапка и подвал всегда были навиду.
«Также видно, что 2 из моих функций вверху списка: decimalToHex и makeColorSorder. Эти 2 функции в сумме занимают 13,2% времени»
«decimalToHex вызывается из makeColorSorter»
в сумме они всё-таки занимают 7.96% ибо total включает в себя время вызовов дочерних функций. и, кстати, лучше нажать на значёк процента, чтобы перевести данные в миллисекунды. если 8% — это жалкие 10мс, то эти оптимизации не стоят потраченного времени.
далее, тормоза первой функции вызваны прежде всего вызовом console.log и если уж и менять реализацию конвертации, то лучше на что-нибудь типа:
return ( d % 0x100 + 0x200 ).toString( 0x10 ).substring( 1 )
оно хотябы не нагенерирует всякой ламбады при передаче чисел вне предполагаемого диапазона
а основные тормоза приложения вообще вызваны слишком частым обращением к дому, о чём никакой профайлер нам ничего не сказал и пришлось догадываться самостоятельно.
вывод: хромовский профайлер — довольно бестолковая вещь, так как не показывает времена выполнения и частоту вызовов апишных функций. а ведь они — основной источник тормозов.
версия с центрированием как по горизонтали так и по вертикали, со скроллингом внутри и прибитыми хедером и футером, размытием страницы, а также возможностью открытия нескольких попапов со сборкой их в стопочку jsfiddle.net/fy48x/6/
выдрано из живого проекта, там только вёрстка. скрипты нужно допилить для себя
не надо тянуть в расширения свои привычки из веб-страничек. у мозиллы есть замечательная технология — xbl, которая позволяет навешивать обработчики, которые сами удаляются при вытаскивании кнопки из дома и добавляются при добавлении.
насчёт валидации — какие-то странные требования. эта «валидация» какую цель преследует?
лениво грузить модули удобно этой штукой: github.com/nin-jin/fenix/blob/master/this.jsm
используется просто:
Compinent.utils.import( 'resource://fenix/this.jsm' )
let $my= $( 'путь к папке модулей' ) // путь может быть относительным или вообще не быть
теперь везде можно использовать например $my.blinker() — при первом обращении будет загружен модуль blicker.jsm и оттуда взят объект blinker
откуда такая уверенность что где должно быть? сегодня у нас пользователь идентифицируется числом, а завтра строкой. и начинается кутерьма «просьба командам всех сервисов бросить все дела и срочно сделать поддержку текстовых идентификаторов иначе мы сейчас сделаем альтер и у вас всё накроется медным тазом». а всё потому что сервера слишком много знали, слишком много делали. они как вахтёры преисполненные чувствовом собственной важности: «мы тут всё контролируем»
база — это инстумент хранения и обеспечения целостности данных. валидация, фильтрация и приведение типов — это лишь частные случаи.
не получим.
все числа в любом случае преобразуются в строку, вот только есть множество различных форматов: с различными разделителями целой и дробной частей, с различными разделителями групп разрядов, в десятичной и экпоненциальных формах. был у меня случай когда программа на яве отказывалась читать числа из файла только потому что у меня была неправильная системная локаль.
я не пишу запросы. я пользуюсь query builder-ом. там нет никаких кавычек, никакого ручного экранирования и тп
а я думаю, что проверка значений должна производиться в одном месте, а не в 10. и если она уже происходит в базе — незачем дублировать её в остальных местах.
вполне себе нормальный способ. все вставлемые значения проходят через один и тот же простой и железный фильтр перед вставкой в строку запроса. ты же предлагаешь усложнить его добавив проверку «если это число, то не экранируем его и не закавычиваем», которая не даёт никаких бенефитов.
именно как имена они и будут восприниматься. обычно используются квадратные скобки или бэктики
настольная клава ноутбучного типа? нахуа? вместо вынесения частых комбинаций на отдельные клавши мы получаем засовывание на одну клавишу десятка функций, переключаемых пятью модификаторами. изначальная идея о настраиваемости и упрощеними работы пошла лесом. красивые дизайн-макеты в реальности воплотить не могут — выглядят как брутальные поделки. из-за того, что изображение фомируется под толстым слоем пластика — смотреть на неё приходится строго вертикально, иначе получаем искривления как на фотке. итого — получилась клава для бабушек с большими кнопками-леденцами и подсветкой. но за такую цену она нафиг никому не нужна. покупать втридорога клаву пошловатой внешности и трахаться потом с её настройкой под разные программы (а иначе она ничем не отличается от обычной клавы) — это нужно быть совсем изнасилованным маркетологами.
идея-то хорошая, древняя и очевидная. но нормальную реализацию пока никто не сделал… одна надежда на эпл — сделают хорошо, потом уже китайцы начнут копировать и продавать по приемлемой цене. итого — не занимайтесь ем, чего не умеете (железо), а сконцентрируйтесь на том что умеете(дизайн-макеты), а для реализации вполне можно договориться с тем же эплом — тогда и качество будет выше и продажи.
> реализации, как всегда, отличаются в IE и не в IE
разумеется все процессоры разные, но почему ие вдруг ставится особняком? xslt придуман не мелкософтом, но реализован ими раньше всех.
> игнорирование первого xsl:call-template
не наблюдаю такого
> и сложными предикатами
например, какими?
> а иногда — загрузка картинки до трансформации.
иногда? какой картинки? откуда?
> Хром требует отличного от других браузеров xsl:output.
какого?
больно уж они похожи на баги, с которыми было лень разбираться и свалили всё на «причуды браузера»
из того, что я знаю, наиболее сильное отличие от остальных — в процессоре мозиллы и то не такие уж страшные, но про неё тут ни слова почему-то.
> Самым популярным способом диагностирования проблем является комментирование кусков шаблона.
это проблема также и любого препроцессора. будь то yate, bemhtml, stylus или любой другой. понять что происходит по нагенеренному коду может только тот, кто этот препроцессор написал (или хорошо его изучил). для остальных же, это чёрный ящик как и xslt.
> в браузере же приходится сильно исхитряться со стандартными средствами, чтобы как-то нестандартно обработать строки
очень спорный момент, должен ли этим заниматься шаблон. но таки да, за возможность запускать его в любом окружении (а не через виртуальную js-машину) приходится платить невозможностью расширить своими прибамбасами.
> E4X на самом деле не очень удобный
да ладно? одно только «root..descendant» чего стоит. или отсутствие «null pointer exception». по скорости — да, не нативно. но вы же яваскрипт не из-за скорости выбрали.
далее, про тесты. я не нашёл в документации делает ли yate автоматическое экранирование данных (и если да, то решили ли вы проблему формирования json внутри html, где нужно двойное экранирование?). если нет экранирования, то тесты не корректны, синтаксис громоздкий, а XSS близко. от какого и до какого момента замерялась скорость (только трансформация или плюс парсинг данных, парсинг шаблона, формирование дома)? дело в том, что xslt позволяет сразу формировать поддерево целевого документа (а значит сериализация и как следствие экранирование не нужны вообще), а yate генерирует строку, которую потом ещё браузеру придётся парсить.
кроме того в xslt есть интересная особенность — многопроходная трансформация, которая сильно помогает в случае, когда данные могут приходить в разных форматах — первым проходом нормализуем данные, а вторым формируем целевой документ.
а в целом — не плохо, хоть один приличный json шаблонизатор. всё остальное либо императивное, либо как мусташ примитивное.
не правильно. читаем приложение А, где собран формальный синтаксис:
path = path-abempty; begins with "/" or is empty
/ path-absolute; begins with "/" but not "//"
/ path-noscheme; begins with a non-colon segment
/ path-rootless; begins with a segment
/ path-empty; zero characters
path-abempty = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty = 0
segment = *pchar
segment-nz = 1*pchar
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
; non-zero-length segment without any colon ":"
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
pct-encoded = "%" HEXDIG HEXDIG
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
упомянутые символы _не требуют_ кодирования процентом в пути, потому что они не могут быть неправильно распознаны (как, например, знак вопроса), хотя и _могут_ быть закодированы, например, в случае, когда нам нужно вставить произвольные данные в произвольное место урла — в этом случае проще воспользоваться одной функцией, которая кодирует все символы имеющие в урле особое значение.
поэтому лучше сравнивать не сырые uri, а нормализованные — тогда никаких петель не будет. «склейщик страниц» тоже наверно не дурак и производит нормализацию ссылок.
работает в мозилле (с типом «application/javascript;version=1.7») и хроме (при включённом «экспериментальном JavaScript»)
осталось дождаться пока генераторы появятся в остальных браузерах
но нет, гипертрофированное эго, убаюкивающее сознание сказкой «я же профессионал», не позволяет попросить совета у сообщества, ведь «там сидят одни дилетанты, далёкие от наших высоконагруженных проблем»
кстати, не пора бы меня снова забанить? а то я тут опять унижаю вас на вашем собственном сайте и пишу не по понятиям великого и могучего…
операции, модели, представления… это же функции, структуры и шаблоны знакомые нам с доисторических времён
а вообще, треугольник этот в клиент-серверную архитектуру не вписывается совершенно — отсюда и столько версий «истинного mvc»
программисты всего мира буквально молятся на эту аббревиатуру, устраивая священные войны о том как правильно её толковать, вместо того, чтобы понять один простой и понятный принцип: если что-то меняется одновременно — выдели их в одну группу, минимизировав число точек контакта с остальным кодом.
если тебуется менять одну субд на другую — выдели код общения с ней в отдельный слой и назови его «драйвер базы данных» или даже «объектно-реляционный преобразователь»
если требуется поддержка разных клиентов — выдели код общения с ними в отдельный слой и назови «фронтальный контроллер». для всяких soap-ов и json-rpc большего и не надо.
если требуется менять формат ответа для одних и тех же возвращаемых данных — выдели код, формирующий ответ в отдельный слой и назови его «представление».
если нужно менять правила работы с данными — выдели их в отдельный код и назови его «бизнес логика».
а если всего этого не надо — фигачь всё вместе, но не забывай, что для разных задач есть разные языки более соответствующие языки: языки программирования, языки шаблонов, языки запросов, языки стилизации, языки настройки, языки сопоставления с образом и многие другие.
и не надо спорить о том сколько слоёв должно быть в приложении — 3 или 4. их может потребоваться гораздо больше. и совершенно не важно как их называть, лишь бы было понятно их предназначение.
в иешках проблема с __defineGetter__
а в геттере только eval происходит, но загрузка должна быть произведена заранее асинхронно?
не то. там у меня ещё всё сыро.
jam — микроядерный яваскриптовый фреймворк nin-jin.github.com/jam/jam/jam.doc.xml
по ссылке собственно пример собранной документации.
сборщик написан на коленке. пока собирает сразу все пакеты и не умеет вычитать модули одного из другого. github.com/nin-jin/web-components/tree/master/so/Compile
как у него с поддержкой ie9-? во время подгрузки скриптов жизнь в браузере замирает?
я вот остановился на такой схеме: всё приложение делится на набор пакетов, пакеты на модули, в модулях уже скрипты, стили, картинки, шаблоны. сборщик пробегается по ним и «собирает пакеты». шаблоны в одну кучку, стили в другую, скрипты в третюю. при этом статически же определяются зависимости: из шаблонов определяется какие компоненты используются и подключаются одноимённые модули (целиком, со всеми ресурсами и их зависимостями), аналогично разруливаются зависимости между скриптами (используется простое соглашение: $jam.Component — модуль Component из пакета jam). в результате получается на каждый тип файла два варианта — отладочный с пофайловым подключением и релизный со слиянием воедино. есть ещё вариант со сквозной минификацией, когда атомы (http://habrahabr.ru/post/97670/) в шаблонах, стилях и скриптах заменяются на короткие
github.com/nin-jin/fenix/blob/master/Factory.jsm
github.com/nin-jin/fenix/blob/master/autoBind.jsm
и получаем:
var Man= Factory( new function( ){
this.name= 'anonymous'
this.init= function( name ){
this.name= name
return this
}
this.scream= function( ){
alert( this.name + '!' )
return this
}
} )
var ninjin= Man( 'Nin Jin' )
setTimeout( ninjin.scream, 1000 ) // кричит «Nin Jin!»
«Также видно, что 2 из моих функций вверху списка: decimalToHex и makeColorSorder. Эти 2 функции в сумме занимают 13,2% времени»
«decimalToHex вызывается из makeColorSorter»
в сумме они всё-таки занимают 7.96% ибо total включает в себя время вызовов дочерних функций. и, кстати, лучше нажать на значёк процента, чтобы перевести данные в миллисекунды. если 8% — это жалкие 10мс, то эти оптимизации не стоят потраченного времени.
далее, тормоза первой функции вызваны прежде всего вызовом console.log и если уж и менять реализацию конвертации, то лучше на что-нибудь типа:
return ( d % 0x100 + 0x200 ).toString( 0x10 ).substring( 1 )
оно хотябы не нагенерирует всякой ламбады при передаче чисел вне предполагаемого диапазона
а основные тормоза приложения вообще вызваны слишком частым обращением к дому, о чём никакой профайлер нам ничего не сказал и пришлось догадываться самостоятельно.
вывод: хромовский профайлер — довольно бестолковая вещь, так как не показывает времена выполнения и частоту вызовов апишных функций. а ведь они — основной источник тормозов.
выдрано из живого проекта, там только вёрстка. скрипты нужно допилить для себя
насчёт валидации — какие-то странные требования. эта «валидация» какую цель преследует?
лениво грузить модули удобно этой штукой: github.com/nin-jin/fenix/blob/master/this.jsm
используется просто:
Compinent.utils.import( 'resource://fenix/this.jsm' )
let $my= $( 'путь к папке модулей' ) // путь может быть относительным или вообще не быть
теперь везде можно использовать например $my.blinker() — при первом обращении будет загружен модуль blicker.jsm и оттуда взят объект blinker
база — это инстумент хранения и обеспечения целостности данных. валидация, фильтрация и приведение типов — это лишь частные случаи.
не получим.
все числа в любом случае преобразуются в строку, вот только есть множество различных форматов: с различными разделителями целой и дробной частей, с различными разделителями групп разрядов, в десятичной и экпоненциальных формах. был у меня случай когда программа на яве отказывалась читать числа из файла только потому что у меня была неправильная системная локаль.
я не пишу запросы. я пользуюсь query builder-ом. там нет никаких кавычек, никакого ручного экранирования и тп
вполне себе нормальный способ. все вставлемые значения проходят через один и тот же простой и железный фильтр перед вставкой в строку запроса. ты же предлагаешь усложнить его добавив проверку «если это число, то не экранируем его и не закавычиваем», которая не даёт никаких бенефитов.
именно как имена они и будут восприниматься. обычно используются квадратные скобки или бэктики
идея-то хорошая, древняя и очевидная. но нормальную реализацию пока никто не сделал… одна надежда на эпл — сделают хорошо, потом уже китайцы начнут копировать и продавать по приемлемой цене. итого — не занимайтесь ем, чего не умеете (железо), а сконцентрируйтесь на том что умеете(дизайн-макеты), а для реализации вполне можно договориться с тем же эплом — тогда и качество будет выше и продажи.