Ну есть же TypeScript. Он вполне себе может помочь с проблемой несовпадения типов. ( compile time only )
По-поводу несовпадения типов и undefined — все известные мне шаблоны ( Handelbars, Mustashe, Jinja2, Razor ect ) зачастую страдают ровно от техже проблем. Есть какие-то примеры шаблонизаторов которые удволетворяют всем требованиям которые вы описываете?
А про отсутствие «нормальных» сообщений об ошибках знаю — но что вообще можно с этим сделать идей никаких нет. Тут даже это не проблема STAN. Это проблема всех шаблонных движков — туда можно отправить undefined или {} — и на выходе получить html.
По поводу Esprime — тоже складывается ощущение что возможно придется его использовать. Пока просто ищу альтернативные пути. Занимающее мало кода.
PS: Не думаю что стоит прятать какие-либо идеи от людей. Даже если они плохие.
Всеравно спасибо за коментарии ( извиняюсь если где-то грубил )
А по поводу «остановиться пока не поздно». Я больше чем уверен что если это плохая идея — она умрет сама сабой. Если все настолько плохо насколько вы описываете то мне не придется прилагать никаких усилий чтобы проект накрылся медным тазом :)
PS: для меня этот проект интересен. На вашем месте я бы наверно тоже не воспринял этот проект серьезно, но не знаю. Возможно это возрастное — подросту — буду умнее. А пока всеравно хочется попробовать насколько далеко можно зайти с подобной идеей. Есть же яркий пример PHP :D
В данной версии 0.2.x — да. Обработчики событий придется навешивать самостоятельно. Пока в раздумиях как можно автоматизировать данный процесс. Если есть хорошие идеи — буду рад их выслушать.
К сожалению вы не правы. В любой более или менее развитый шаблонизатор можно запихнуть бизнес логику. Можно != нужно. Что вам мешает разделить код шаблонов от кода бизнес логики? Ничего. Держите код шаблонов в отдельном месте и не пишите там бизнес логику. Все просто
Я очень не люблю идею — давайте затупим скальпель а то люди могут им пораниться. Не надо делать инструменты тупее. Нужно людей делать умнее.
По поводу «путания шаблонов и логики» — могу сказать только одно. Не путайте. Данная библиотека тут ни причем.
По поводу безопасности. Вас никто не заставляет тащить саму библиотеку STAN в проект. Пока к сожалению у меня небыло времени написать препроцессор — но вы сами можете довольно легко его написать и ложить в проект только скомпилированные шаблоны — и никаких eval не будет. PS: Постараюсь как можно быстрее написать плагины для Grunt и Gulp.
По поводу «вот это шаблоны» — Вы привели явно не лучшие примеры, но всеравно. Скажите. В каком из них для прохода по массиву я могу использовать lodash? ;)
Ну вот а я реально забываю. Меня часто отвлекаю и иногда по очень важным вопросам. Смотрю обратно на клавиатуру и приходится методом тыка узнавать в каком состоянии кнопка. Можете спросить у любого дизайнера — есть такой принцип разработки интерфейса. Что если пользователя отвлекут и он снова смотрит на интерфейс — он должен сразу сказать в каком состоянии что и как находится. Почему я должен постоянно помнить включил я CAPS или нет? Ну сравните — просто сравните www.youtube.com/watch?feature=player_detailpage&v=Bo-z_o_8xtM — не думаю что «новомодный» плоский интерфейс стоил того чтобы сделать клавиатуру менее понятной.
Если говорить серьезно с моей стороны претензии такие:
1) Новые иконки, которые иногда приходится сначало дешифровать чтобы понять ( местами просто переборщили с символизмом )
2) Не доработанный UI. Явно спешили с релизом. ( но это сильно субьективный аргумент )
3) Непонятные состояния у клавиатурной клавишы shift ( постоянно путаю включен ли Caps или нет )
4) Изменения ради изменений в календаре ( я про приложение )
5) Интерфейс совершенно не красивый ( не только мое мнение — поищите отзывы в Twitter — должен правда признать что есть и сильно положительные отзывы )
6) Нижная панель — с громкостью и прочим — стало невозмодно пользоваться. Очень маленькие контролы скучкованные друг с другом. ( девайс iPad mini )
А теперь отвернитесь, подождите немного, повернитесь обратно… сложно передать сколько раз уже ошибался думаю что CAPS выключен или включен. Я понимаю что это может быть из за «моей глупости» — но скажем так, почему она не проявлялась в iOS 6.x?
А давайте я сам развенчаю эти «мифы»
( статья кстати — маркетинговый треш — я про оригинал — не про перевод )
Миф #1 — У Apple — лучшие дизайнеры
Конечно это не правда. Посмотрите на то уг также известное как iOS 7.x. Вы блин видели конда-нибудь клавитуру где небыло бы понятно включил ты CAPS LOCK или нет? -..-
Миф #2 — У Apple безумно большая команда дизайнеров
Не могло много дезайнеров произвести на свет iOS 7.x — команда у Apple маленькая. Если бы у них было много людей хоть один бы да взбунтовался.
Миф #3 — Apple намеренно прорабатывает каждую деталь
Я с вами согласен. Данный инструмент ( PageSpeed Analizer ) далек от совершенства — мало того они навязывают свое видение «быстрого и качественного» сайта (аргументированно — но всеже). Я к тому что Flash ( по их мнению ) уже туда не входит. Когда они говорят «найдите замену» — они фактически говорят «удалите флеш» :/
А кому нужен Flash на мобильных девайсах ( вы не забывайте что статья про оптимизацию под мобильные девайсы)? Вы о чем? Apple iOS и Windows Phone — с самого рождения не поддерживают Flash. Google Chrome под Android перестал поддерживать Flash ( или изначально не поддерживал ). Google вам мягко намекает что даже им уже Flash не интересен. И они вас просят не подключать замену Flash — а выкинуть Flash и использовать HTML5
// скорее всего мы в IE - Metro mode ( IE10+ )
if(navigator.msMaxTouchPoints && navigator.msMaxTouchPoints > 0) { ... }
Код не дает 100% гарантии что юзверь пользуется пальцами а не мышью и что он находиться именно в Metro, но лично мне этот код помог и он достаточно хорошо работает
Не сочтите за холивар, говорю так для справки. На Windows Phone официальное бесплатное приложение от MS по переводу умело работать офлайн уже пол года назад.
По-поводу несовпадения типов и undefined — все известные мне шаблоны ( Handelbars, Mustashe, Jinja2, Razor ect ) зачастую страдают ровно от техже проблем. Есть какие-то примеры шаблонизаторов которые удволетворяют всем требованиям которые вы описываете?
А про отсутствие «нормальных» сообщений об ошибках знаю — но что вообще можно с этим сделать идей никаких нет. Тут даже это не проблема STAN. Это проблема всех шаблонных движков — туда можно отправить undefined или {} — и на выходе получить html.
По поводу Esprime — тоже складывается ощущение что возможно придется его использовать. Пока просто ищу альтернативные пути. Занимающее мало кода.
PS: Не думаю что стоит прятать какие-либо идеи от людей. Даже если они плохие.
А по поводу «остановиться пока не поздно». Я больше чем уверен что если это плохая идея — она умрет сама сабой. Если все настолько плохо насколько вы описываете то мне не придется прилагать никаких усилий чтобы проект накрылся медным тазом :)
PS: для меня этот проект интересен. На вашем месте я бы наверно тоже не воспринял этот проект серьезно, но не знаю. Возможно это возрастное — подросту — буду умнее. А пока всеравно хочется попробовать насколько далеко можно зайти с подобной идеей. Есть же яркий пример PHP :D
>>
Вы явно любите говорить о том о чем не знаете. Что пичально.
Строчка «div.context.foo.bar.baz.qux» моментально падает с ошибкой.
>> я ради разминки написал «супер быстрый» и короче вашего на 4 строки
Ну во-первых ваш шаблонизатор не совместим ни с jsbin ни с jsfiddle
jsbin.com/tazulewe/20/edit
Оставляю вам это как ДЗ ( если совсем лень — вот вам подсказка — добавьте где угодно в JS коментарий — //noprotect )
Во-вторых. У вас нет возможности вызвать один шаблон из другово. Так что «не удивительно» что ваш код короче на 4 строчки.
>> Вот смотрите…
Кстати, спасибо — подтолкнули на ряд идей, по оптимизации. Плюс нашел ряд проблем как у вас так и у себя.
>> пилить статью? :]
Ну, вы не маленький, думаю сможете для себя сами решить :)
Отлаживать данный шаблонизатор удобнее чем любой существующий, ибо по сути мы просто отлаживаем JS.
От JSHint можно избавится /* jshint expr:true */ ( поместив это только в файлы шаблонов )
Ну а бенчмарк вы всегда можете сравнить сами
jsperf.com/javascript-templating-shootoff-extended/92
спасибо sferrka — абсолютно верно подмечанно. правда компонет Alert в терминах STEN пока реализовываеться вот таким способом
function _alert(){
div['class="alert"'].context.div;
}
и переиспользуеться он в большом шаблоне вот так
function _template(){
partial(_alert, "Hello world");
}
что в свою очеред компилируеться в
function compiled__alert(context,r){
r=r||"";
r+='<div '+('class="alert"')+'>'+(context)+'</div>';
return r
}
to erlioniel
К сожалению вы не правы. В любой более или менее развитый шаблонизатор можно запихнуть бизнес логику. Можно != нужно. Что вам мешает разделить код шаблонов от кода бизнес логики? Ничего. Держите код шаблонов в отдельном месте и не пишите там бизнес логику. Все просто
Я очень не люблю идею — давайте затупим скальпель а то люди могут им пораниться. Не надо делать инструменты тупее. Нужно людей делать умнее.
to printf
По поводу «путания шаблонов и логики» — могу сказать только одно. Не путайте. Данная библиотека тут ни причем.
По поводу безопасности. Вас никто не заставляет тащить саму библиотеку STAN в проект. Пока к сожалению у меня небыло времени написать препроцессор — но вы сами можете довольно легко его написать и ложить в проект только скомпилированные шаблоны — и никаких eval не будет. PS: Постараюсь как можно быстрее написать плагины для Grunt и Gulp.
По поводу «вот это шаблоны» — Вы привели явно не лучшие примеры, но всеравно. Скажите. В каком из них для прохода по массиву я могу использовать lodash? ;)
" Grey button with a white arrow: Caps off
Серая кнопка с белой стрелкой — Caps выключен
White button with a black arrow: Caps shift for a single character
Белая кнопка с черной стрелкой — Caps для одной буквы
White button with a black arrow and black underline: Caps lock on
Белая кнопка с черной стрелкой и черным подчеркиванием — Caps включен "
+ ну согласитесь если бы вам дали три бумажки с этими иконками — вы бы не смогли сказать где caps включен а где выключен
1) Новые иконки, которые иногда приходится сначало дешифровать чтобы понять ( местами просто переборщили с символизмом )
2) Не доработанный UI. Явно спешили с релизом. ( но это сильно субьективный аргумент )
3) Непонятные состояния у клавиатурной клавишы shift ( постоянно путаю включен ли Caps или нет )
4) Изменения ради изменений в календаре ( я про приложение )
5) Интерфейс совершенно не красивый ( не только мое мнение — поищите отзывы в Twitter — должен правда признать что есть и сильно положительные отзывы )
6) Нижная панель — с громкостью и прочим — стало невозмодно пользоваться. Очень маленькие контролы скучкованные друг с другом. ( девайс iPad mini )
( статья кстати — маркетинговый треш — я про оригинал — не про перевод )
Миф #1 — У Apple — лучшие дизайнеры
Конечно это не правда. Посмотрите на то уг также известное как iOS 7.x. Вы блин видели конда-нибудь клавитуру где небыло бы понятно включил ты CAPS LOCK или нет? -..-
Миф #2 — У Apple безумно большая команда дизайнеров
Не могло много дезайнеров произвести на свет iOS 7.x — команда у Apple маленькая. Если бы у них было много людей хоть один бы да взбунтовался.
Миф #3 — Apple намеренно прорабатывает каждую деталь
ЧТО? о_О Чувак создал этот «проработанный» дизайн iOS 7.x в MS Word
www.youtube.com/watch?v=RZp7BvQJnU8
Миф #4 — Пыл Стива Джобса всех пугал
При Джобсе такой Х$*##и небыло…
P.S. Я говорил что мне не нравиться дизайн iOS 7.x? :)
P.P.S. Простите за толстый троллинг. Накипело.
Код не дает 100% гарантии что юзверь пользуется пальцами а не мышью и что он находиться именно в Metro, но лично мне этот код помог и он достаточно хорошо работает
www.windowsphone.com/ru-ru/store/app/translator/2cb7cda1-17d8-df11-a844-00237de2db9e