Ключевая идея RESTAS
Насколько я понял главное - это маршруты.
То есть возможность задать некий шаблон для строки запроса из которой будут вытаскиваться параметры, так?
У меня возможно не получается оценить все преимущества ...
Возьмём пример из твоего блога
То есть возможность задать некий шаблон для строки запроса из которой будут вытаскиваться параметры, так?
У меня возможно не получается оценить все преимущества ...
Возьмём пример из твоего блога
"Hello World" с RESTAS
(define-route chapter-?-?.html ("chapter-:(id1)-:(id2).html")
(who:with-html-output-to-string (out)
...
Тут всё ясно как день, прямо в предполагаемой строке запроса задаём параметры id1, id2 и
далее ими пользуемся в своём коде. Действительно удобно. Но какое реальное преимущество
перед простым заданием параметров, например так:
(define-easy-handler (myhandler "/myhandler") (id1 id2)
...)
Здесь главное это принцип, define-easy-handler имеет свои недостатки (в частности нельзя
указывать host)
Соответственно ссылка на клиенте будет подобна следующей : <a href=chapter.html?id1=2&id2=3> link </a>
Согласен с тем, что здесь проигрыш в декларативности на стороне клиента, однако
это стандартный способ передачи параметров на сервер. Я собственно хотел бы услышать
плюсы подхода restas. Усложнять код сервера, для того чтобы заменить стандартный способ
передачи параметров ...
Стоит ли игра свеч?
[#]
> Насколько я понял главное - это маршруты.
Не только, ключевые идеи:
- маршруты (routes)
- модули (поддержка повторого использования)
- виртуальные хосты
- полная интерактивность разработки (например, в обычном hunchentoot ты не можешь просто так изменить таблицу маршрутизации уже запущенного сервера)
- Интеграция с Emacs via SLIME (пока в ограниченном объёме).
> однако это стандартный способ передачи параметров на сервер.
Это не стандартный, это просто метод передачи GET-параметров, но поскольку в PHP без использования mod_rewrite нельзя организовать человеческие URL, то подобные способ встречает черезвычайно широко. Читай про ЧПУ и почему обычный PHP-стиль просто ужасен.
Маршруты обеспечивают:
- ЧПУ
- Автоматический let для переменных шаблона URL в обработчике, в том числе, с использованием указанных функций для парсинга параметров
- Гибкие условия для выбора "правильного" маршрута. Т.е. для одного и того же шаблона url может быть несколько маршрутов, для разных условий. Например, разные обработчики для разных типов запроса (GET/POST/etc), или проверка содержимого cookie, ну вообще какие угодно проверки на стадии диспетчеризации. Это обеспечивает существенное уменьшение if-лапши в коде.
Вообще, routes это некий, довольно продвинутый, аналог pattern matching для обработки поступающих запросов.
[#]
Класс!!! Перечитал все твои блоги по RESTAS и почти все по CL-CLOSURE-TEMPLATE. Очень понравился дизайн кода. Подумываю о том, чтобы перевести http://clisp.linkfly.ru и http://linkfly.ru на RESTAS
Практически полностью солидарен в выборе концепций. Правда в использовании CL-CLOSURE-TEMPLATE пока неуверен (наверное надо ещё почитать) но выглядит это очень простым и перспективным. Не совсем понял твоего высказывания: "CL-WHO применять для больших проектов не советую" (или как-то так). Почему??
Практически полностью солидарен в выборе концепций. Правда в использовании CL-CLOSURE-TEMPLATE пока неуверен (наверное надо ещё почитать) но выглядит это очень простым и перспективным. Не совсем понял твоего высказывания: "CL-WHO применять для больших проектов не советую" (или как-то так). Почему??
[#]
> Класс!!!
Я рад, что тебе понравилось (хоть кому-то) ;)
> Не совсем понял твоего высказывания: "CL-WHO применять для больших проектов не советую"
У CL-WHO три очевидных для меня проблемы (думаю, при желании их можно выделить больше).
- Идея использования s-выражений для генерации html очень сомнительна. Это реально очень не удобно если говорить о какой-либо более-менее сложной разметке и реальном процессе разработки. Это можно было бы принять из большой любви к скобочкам (у меня такой, увы, нет), но что делать с дизайнерами, JS-программистами и прочими реалями production?
- Технически это очень примитивная библиотека, которая не предоставляет даже минимально необходимого для реальной работы функционала. Например, просто так собирать страницу из отдельных компонентов с помощью cl-who не получиться. Это, в принципе, можно сделать, если покопаться в исходниках и заюзать неэкспортируемые функции, но это всё равно останется костылем. Всё что можно делать с её помощью - это генерировать целые страницы за раз. Очевидно, что сам автор её реально для чего-либо сложного не использует.
- Она гвоздями прибита к HTML 4.
[#]
> Идея использования s-выражений для генерации html очень сомнительна.
Это реально очень не удобно если говорить о какой-либо более-менее
сложной разметке и реальном процессе разработки
Думаю, если применять без фанатизма - то всё отлично получается. Например, использовать для динамического вычисления и загрузки результатов на клиент посредством ajax. На клиентах всё-таки пока ещё, так сказать, xml-like software. Так что в этом смысле, применение s-expressions весьма удобно.
>Это можно было бы принять из большой любви к скобочкам (у меня такой, увы, нет)
Странно слышать это от человека, пишущего о символьных вычислениях и на практике применяющего (причём весьма успешно) s-выражения . . .
>но что делать с дизайнерами, JS-программистами и прочими реалями production?
Ничего не делать! Ну, по-возможности. На мой взгляд надо стремится оставлять клиентские технологии клиенту. Лисп отлично себя чувствует, и отлично справляется с задачами обработки на сервере. Не надо его заставлять возится с нюансами работы клиента (как впрочем и вообще серверный софт). По крайней мере надо к этому стремится. Я видел как в рельной жизни java-программисты херачит в одну кучу и серверную обработку и клиентскую ... и html и css и javascript и jsf и java и ... короче эти ребята обеспечили себя работой над проектом на "века-вечные" :))
> Всё что можно делать с её помощью - это генерировать целые страницы за раз.
Как я уже сказал выше - сила в простоте, лучше использовать ещё исключительно для динамической подгрузки данных. С задачей генерации небольшого куска вёрстки она справляется отлично.
> Очевидно, что сам автор её реально для чего-либо сложного не использует.
Да и не надо ему её усложнять. Если нам нужно мы можем сделать ASDF-систему с зависимостью от CL-WHO и добавить нужные нам фичи.
> Она гвоздями прибита к HTML 4.
Не прибита - я использовал её для генерации XHTML Transitional, причём как целиком страниц, так и частей разметки.
Думаю, если применять без фанатизма - то всё отлично получается. Например, использовать для динамического вычисления и загрузки результатов на клиент посредством ajax. На клиентах всё-таки пока ещё, так сказать, xml-like software. Так что в этом смысле, применение s-expressions весьма удобно.
>Это можно было бы принять из большой любви к скобочкам (у меня такой, увы, нет)
Странно слышать это от человека, пишущего о символьных вычислениях и на практике применяющего (причём весьма успешно) s-выражения . . .
>но что делать с дизайнерами, JS-программистами и прочими реалями production?
Ничего не делать! Ну, по-возможности. На мой взгляд надо стремится оставлять клиентские технологии клиенту. Лисп отлично себя чувствует, и отлично справляется с задачами обработки на сервере. Не надо его заставлять возится с нюансами работы клиента (как впрочем и вообще серверный софт). По крайней мере надо к этому стремится. Я видел как в рельной жизни java-программисты херачит в одну кучу и серверную обработку и клиентскую ... и html и css и javascript и jsf и java и ... короче эти ребята обеспечили себя работой над проектом на "века-вечные" :))
> Всё что можно делать с её помощью - это генерировать целые страницы за раз.
Как я уже сказал выше - сила в простоте, лучше использовать ещё исключительно для динамической подгрузки данных. С задачей генерации небольшого куска вёрстки она справляется отлично.
> Очевидно, что сам автор её реально для чего-либо сложного не использует.
Да и не надо ему её усложнять. Если нам нужно мы можем сделать ASDF-систему с зависимостью от CL-WHO и добавить нужные нам фичи.
> Она гвоздями прибита к HTML 4.
Не прибита - я использовал её для генерации XHTML Transitional, причём как целиком страниц, так и частей разметки.
[#]
> Например, использовать для динамического вычисления и загрузки результатов на клиент посредством ajax.
Если говорить об AJAX, то cl-closure-template + JSON, это то, что реально удобно.
> Странно слышать это от человека .. применяющего .. s-выражения . .
Я отношусь к скобочкам как к синтаксису. Такой синтаксис, что тут можно сделать. Каких-либо особых чувств у меня к нему нет. Кое в чём, s-выражения обеспечивает достаточно уникальный функционал и от них трудно отказаться. С другой стороны, во многих случаях традиционный синтаксис лучше подходит для написания кода. Об этом можно рассуждать, а можно и нет, ибо это данность, которую надо либо принять, либо отказаться.
> На мой взгляд надо стремится оставлять клиентские технологии клиенту.
Я долго работал по схеме, где серверный код предоставлял только API, а генерация реального контента производилась полностью на клиенте. В итоге, решил отказаться, во много для упрощения клиентского кода. А то ведь на сервере такой мощный язык, а его возможности не задействованы ;)
> Не прибита - я использовал её для генерации XHTML Transitional
А, да, она ещё умеет и это, но мне надо генерировать SVG и cl-who нервно курит в сторонке. Нет, там реально в код вбиты детали html, это не нормально. Шаблон страницы должен быть похож на страницу.
[#]
>Я рад, что тебе понравилось (хоть кому-то) ;)
Мне тоже понравилось.
>Например, использовать для динамического вычисления и загрузки результатов на клиент посредством ajax.
Для ajax лучше подойдет пересылка только данных, и генерация разметки на клиенте. Мне в этом плане очень нравится библиотека ExtJS - там есть практически все для быстрого и простого написания клиентов на html & js.
У cl-who, несмотря на его недостатки, есть плюс - это возможность использования квазицитированных вычисляемых фрагментов. Хотя мне для генерации SVG гораздо больше понравился cxml.
>Нет, там реально в код вбиты детали html, это не нормально.
В xml-режиме он может генерировать все, что угодно. Если это "что угодно" не использует неймспейсы.
Мне тоже понравилось.
>Например, использовать для динамического вычисления и загрузки результатов на клиент посредством ajax.
Для ajax лучше подойдет пересылка только данных, и генерация разметки на клиенте. Мне в этом плане очень нравится библиотека ExtJS - там есть практически все для быстрого и простого написания клиентов на html & js.
У cl-who, несмотря на его недостатки, есть плюс - это возможность использования квазицитированных вычисляемых фрагментов. Хотя мне для генерации SVG гораздо больше понравился cxml.
>Нет, там реально в код вбиты детали html, это не нормально.
В xml-режиме он может генерировать все, что угодно. Если это "что угодно" не использует неймспейсы.
[#]
> CL-WHO
Он очень для спецефичного круга задач. Лучше использовать html-template или archimag'а cl-closure-templates. Ипользовать cl-who там где его не нужно использовать не есть правильно.
[#]
> С другой стороны, во многих случаях традиционный синтаксис лучше подходит для написания кода
В корне не согласен. Я использовал очень много языков с традиционным и не очень синтаксисом и со всей ответственностью утверждаю что для написания кода практически во всех случаях лучше подходят S-expressions. Ну да ладно, склонен думать что ты так говоришь, просто потому что "в чужом огороде трава зеленей" ))
Всё же Лисп это не только S-выражения но и ещё очень и очень много других концепций (многие из которых правда базируются на s-выражениях ;)).
> А, да, она ещё умеет и это, но мне надо генерировать SVG
Если я не ошибаюсь это формат векторной графики? Ну так, как говориться "разделяй и властвуй".
> Нет, там реально в код вбиты детали html, это не нормально
Не понимаю, как это "вбиты детали html"? Мы же можем писать например, так:
(with-html-output-to-string (out)
(:body (:mytag "sdf")))
то есть спокойно использовать свои теги, аа.. то есть weitz может быть для известных тегов использует захардкоденные строки, а для неизвестных -
превращает их в строку?
В корне не согласен. Я использовал очень много языков с традиционным и не очень синтаксисом и со всей ответственностью утверждаю что для написания кода практически во всех случаях лучше подходят S-expressions. Ну да ладно, склонен думать что ты так говоришь, просто потому что "в чужом огороде трава зеленей" ))
Всё же Лисп это не только S-выражения но и ещё очень и очень много других концепций (многие из которых правда базируются на s-выражениях ;)).
> А, да, она ещё умеет и это, но мне надо генерировать SVG
Если я не ошибаюсь это формат векторной графики? Ну так, как говориться "разделяй и властвуй".
> Нет, там реально в код вбиты детали html, это не нормально
Не понимаю, как это "вбиты детали html"? Мы же можем писать например, так:
(with-html-output-to-string (out)
(:body (:mytag "sdf")))
то есть спокойно использовать свои теги, аа.. то есть weitz может быть для известных тегов использует захардкоденные строки, а для неизвестных -
превращает их в строку?
[#]
>то есть weitz может
быть для известных тегов использует захардкоденные строки
Нет, в html некоторые элементы не имеют закрывающих тегов, только открывающие (например, img, meta, link). Список этих тегов есть в сорцах cl-who.
Нет, в html некоторые элементы не имеют закрывающих тегов, только открывающие (например, img, meta, link). Список этих тегов есть в сорцах cl-who.
[#]
to dmitry_vk:
> Для ajax лучше подойдет пересылка только данных, и генерация разметки на клиенте. Мне в этом плане очень нравится библиотека > ExtJS - там есть практически все для быстрого и простого написания клиентов на html & js.
ExtJS не нужна :) Не, правда, монстр тот ещё... Я когда-то (ещё до лиспа) пересмотрел много разных JS-фреймворков (самый ужасный, конечно, Dojo) и в итоге пришёл к jquery (без jquery.ui). А проблема генерации контента на клиенте сейчас полностью решил как раз за счёт cl-closure-template: получил с сервера JSON, подставил его сразу в шаблон (который просто js-функция) и получил разметку. С jquery сочетается просто идеально.
> Хотя мне для генерации SVG гораздо больше понравился cxml.
Мне надо генерить его как на сервере, так и на клиенте, так что вариант только один - cl-closure-template. Я делал специально для генерации xml в cl-libxml2 отдельный комопнент - xfactory, мне в общем нравиться как он работает, но сейчас всё равно предпочитаю для всех подобных задач cl-closure-template. Сто бед - один ответ :)
to LinkFly:
> Я использовал очень много языков с традиционным и не очень синтаксисом и со всей ответственностью утверждаю
> что для написания кода практически во всех случаях лучше подходят S-expressions.
Ну я как бы тоже не на одном писал ;) Сейчас постоянно пишу на CL и JS, и что-то в плане синтаксиса мне нравиться в CL, а что-то в JS. В CL часто плотность кода получается очень высокая, это не всегда хорошо.
[#]
А что значит, высокая плотность кода? Когда написано мало а толку много? В случае разных Perl'ов, или скажем регулярок, соглашусь да - такая плотность кода не есть хорошо (разве что для маньяка который натоскал себя на извращённый синтаксис и ловит кайф, когда никто не может понять что он там понаписал ;)). Но в случае s-expressions когда это плохо? Разве только тогда, когда уж совсем кривой дизайн, ну так это всех языков касается.