Если вы хотите писать на dap, то JS — ваш главный помощник, на самом деле. Из второй части этого туториала это будет более понятно.
Мякотка dap вовсе не в этих *?!
я мог бы их назвать for-each, if, print. Просто зачем? Я вот сейчас реально перечислил все три(!) основных оператора, которые вам нужно «выучить», чтобы начать писать на dap. Выучить три оператора — это сложно, я понимаю, но мы не на ЕГЭ, тут дело добровольное. А, собственно, мякотка dap в том, что он позволяет просто и коротко описывать то, что средствами JS пишется громоздко, муторно и просто некрасиво. При этом dap не пытается лезть туда, где все можно просто и красиво сделать на JS. Дождитесь второй части туториала.
Зачем нужен JS — кстати это хороший вопрос, я вам с удовольствием отвечу. Изначально (2008-м году, bankreports.dapmx.org) дап строился на HTML/XML. Правила писались в атрибутах d, u и т.п. В принципе это было вполне удобно (в отличие от js-строк, SGML-атрибуты могут быть многострочными, этого сейчас иногда не хватает) и выглядело в те времена доминирования XML вполне логично (хотя синтаксис самих dap-правил был действительно адский). Но в какой-то момент я подумал: а нахрена? Зачем писать это тегами, потом парсить это все, собирать в объекты, иметь вот этот весь головняк, если все это можно прекрасно сделать средствами самого JS? Так же как сейчас я не понимаю этого прикола JSX писать в JS-коде HTML-теги.
Поэтому сейчас dap строится средствами JS, и манипулировать dap-шаблонами можно любыми доступными в JS средствами — это обычные JS объекты из обычных JS-объектов. Смысла городить отдельный язык с компилятором и монадами я просто не вижу.
В отличие от помянутых PureScript, ClojureScript, CoffeeScript, которые «вместо» JS, dap не вместо.
На какой-то странной мысли вы себя поймали. Те, кому не интересен JS, пишут на TS, на JSX и прочих «более интересных» языках, как раз таки компилируемых в JS. Все как вы хотите.
А вот dap как раз обходится средствами голого JS. И почему вы думаете, что выслушивать вопли «JS-еров»-неофитов — это что-то плохое? :)
Непонятно, что вы называете безумием решеток и кавычек. Обилие решеток здесь — это «безумие» CSS-файла, который писал не я, и который к dap отношения не имеет. Кавычки и скобочки вас пугают? А вы когда на JS/HTML последний раз писали? Сравните, пожалуйста, на количество кавычек и скобочек (и их видов) вот эти два выражения:
Это как раз не самостоятельные куски кода, а фрагменты, в которые внесены изменения. Если сравнивать эти фрагменты с предыдущими — отступы помогают сориентироваться, какая именно строка изменена. Ну так, по крайней мере, задумывалось. Такое «скользящее окно».
Дисклеймер: если вы зашли в комментарии для того, чтобы сообщить о том, что dap вам не нравится и вы никогда не будете им пользоваться — сначала загляните, пожалуйста сюда. Спасибо за понимание.
Если у вас вопрос «а как на dap сделать X, да так чтобы Y» или аналогичный — буду рад ответить во всех подробностях.
А. Пардон. Если речь про «придумать синтаксис, основываясь на синтаксисе js», то тут я с вами соглашусь, лучше на просто js. Хотя jQuery-фаги так не считают.
(ссылка на TodoMVC, похоже, битая, поправьте. Я нашел ее в статье, работает) Посмотрел. Похоже, мы с вами с ровно противоположных сторон подходим к проблеме :)
Вам мало фреймворков, основанных на js? Если вам так сложно переключиться с js-синтаксиса — ок, проходите мимо. Проблема с js в том, что он не предназначен, для того, что делает dap. А dap не предназначен для того, что легко делается на js.
В dap можно провернуть все, что можно провернуть в js. Dap — это не «язык вместо js», а просто средство передачи данных от одного элемента другим.
Что касается обработки запросов.
Конвертор :query — для ленивых (лично я пока реально пользовался только им). Он получает данные, парсит их в соответствии с mime типом и отдает результат. Если что-то пошло не так, он просто отдает «ничто». Если вам не важно, что именно пошло не так (обычно так и есть, это нормальное для браузера поведение), и достаточно просто выдать ошибку вида «ой!», то это будет что-то вроде: ? $data=myDataUrl:query errorMessage:alert; .... используем $data ....
Если вам надо прям все знать, то можно воспользоваться более низкоуровневым конвертором :request, который просто выполняет запрос и отдает его как есть, со всеми потрохами: $req=myDataUrl:request; ! $req.status $req.headers и т.д.
Если вы хотите вообще как-то хитро запросы делать, можете сделать свой конвертор, с блэкджеком прогрессбаром и алертами и пользоваться им: $data=myDataUrl:myFancyDataLoader
В принципе это тема для отдельной статьи. Не конкретно обработка ошибок загрузки, а использование собственных функций. То, что дапа будет выглядеть простым конвертором, на деле вполне может быть жыыырным черным ящиком, именно спрятанным под капот.
Нет, я его, можно считать, еще не публиковал. Пользуюсь сам для своих нужд около 10 лет.
Из примеров: bankreports-dapmx-o.1gb.ru (самое первое dap-приложение 2008-го года, ныне заброшеное), bazamagaza-com.1gb.ru (интернет-магазин/склад/crm в одном флаконе, тоже достаточно древний) dapmx.org/apps/rockauto (простой фронтенд к магазину автозапчастей)
Боевые проекты в открытый доступ дать не могу. т.к. там живые клиенты с данными.
Если будет интерес у почтенной публики, распишу процесс подробно на примере несложного PWA приложения, которое хочу запустить в ближайшее время.
Просто аналогичные игры в ассоциации уже были в комментах к предыдущей статье. Кто какой js раньше видел, тому то и мерещится. Я думаю, это нормально.
Мякотка dap вовсе не в этих *?!
я мог бы их назвать for-each, if, print. Просто зачем? Я вот сейчас реально перечислил все три(!) основных оператора, которые вам нужно «выучить», чтобы начать писать на dap. Выучить три оператора — это сложно, я понимаю, но мы не на ЕГЭ, тут дело добровольное. А, собственно, мякотка dap в том, что он позволяет просто и коротко описывать то, что средствами JS пишется громоздко, муторно и просто некрасиво. При этом dap не пытается лезть туда, где все можно просто и красиво сделать на JS. Дождитесь второй части туториала.
Зачем нужен JS — кстати это хороший вопрос, я вам с удовольствием отвечу. Изначально (2008-м году, bankreports.dapmx.org) дап строился на HTML/XML. Правила писались в атрибутах d, u и т.п. В принципе это было вполне удобно (в отличие от js-строк, SGML-атрибуты могут быть многострочными, этого сейчас иногда не хватает) и выглядело в те времена доминирования XML вполне логично (хотя синтаксис самих dap-правил был действительно адский). Но в какой-то момент я подумал: а нахрена? Зачем писать это тегами, потом парсить это все, собирать в объекты, иметь вот этот весь головняк, если все это можно прекрасно сделать средствами самого JS? Так же как сейчас я не понимаю этого прикола JSX писать в JS-коде HTML-теги.
Поэтому сейчас dap строится средствами JS, и манипулировать dap-шаблонами можно любыми доступными в JS средствами — это обычные JS объекты из обычных JS-объектов. Смысла городить отдельный язык с компилятором и монадами я просто не вижу.
В отличие от помянутых PureScript, ClojureScript, CoffeeScript, которые «вместо» JS, dap не вместо.
Похоже, вы не от CSS сильно отстали :)
А вот dap как раз обходится средствами голого JS. И почему вы думаете, что выслушивать вопли «JS-еров»-неофитов — это что-то плохое? :)
Непонятно, что вы называете безумием решеток и кавычек. Обилие решеток здесь — это «безумие» CSS-файла, который писал не я, и который к dap отношения не имеет. Кавычки и скобочки вас пугают? А вы когда на JS/HTML последний раз писали? Сравните, пожалуйста, на количество кавычек и скобочек (и их видов) вот эти два выражения:
Мою либу вы можете проинсталить, просто взяв файл dap.js.org/0.4.js если хотите.
Другое дело, что это именно «не нужно», в смысле «не требуется».
Получение данных в UI не лучший подход. — это было бы справедливо, если вместо "UI" написать "view".
Dap — программа это не view.
Про рекламу и монетизацию — идея хорошая, спасибо :)
Если у вас вопрос «а как на dap сделать X, да так чтобы Y» или аналогичный — буду рад ответить во всех подробностях.
Забей. Это не твое
(ссылка на TodoMVC, похоже, битая, поправьте. Я нашел ее в статье, работает) Посмотрел. Похоже, мы с вами с ровно противоположных сторон подходим к проблеме :)
Формального регламента я, правда, не нашел, среверсил отсюда
Что касается обработки запросов.
Конвертор
:query— для ленивых (лично я пока реально пользовался только им). Он получает данные, парсит их в соответствии с mime типом и отдает результат. Если что-то пошло не так, он просто отдает «ничто». Если вам не важно, что именно пошло не так (обычно так и есть, это нормальное для браузера поведение), и достаточно просто выдать ошибку вида «ой!», то это будет что-то вроде:? $data=myDataUrl:query errorMessage:alert; .... используем $data ....Если вам надо прям все знать, то можно воспользоваться более низкоуровневым конвертором
:request, который просто выполняет запрос и отдает его как есть, со всеми потрохами:$req=myDataUrl:request; ! $req.status $req.headers и т.д.Если вы хотите вообще как-то хитро запросы делать, можете сделать свой конвертор, с
блэкджекомпрогрессбаром и алертами и пользоваться им:$data=myDataUrl:myFancyDataLoaderВ принципе это тема для отдельной статьи. Не конкретно обработка ошибок загрузки, а использование собственных функций. То, что дапа будет выглядеть простым конвертором, на деле вполне может быть жыыырным черным ящиком, именно спрятанным под капот.
Из примеров:
bankreports-dapmx-o.1gb.ru (самое первое dap-приложение 2008-го года, ныне заброшеное),
bazamagaza-com.1gb.ru (интернет-магазин/склад/crm в одном флаконе, тоже достаточно древний)
dapmx.org/apps/rockauto (простой фронтенд к магазину автозапчастей)
Боевые проекты в открытый доступ дать не могу. т.к. там живые клиенты с данными.
Если будет интерес у почтенной публики, распишу процесс подробно на примере несложного PWA приложения, которое хочу запустить в ближайшее время.