Я тут потихоничку (вот уже второй день ) работаю над созданием макроса xml-литерал.
Общая идея такая... в коде можно будет описывать ХМЛ-литералы на подобие того как это сделано в ВБ. На выходе будет линковских XElement. Они будут подерживать классические немерловые квази-цитаты.
Кроме того я планирую сделать их "активными". Это значит, что вних можно будет описывать логику генерации ХМЛ-я. Причем прямо в виде ХМЛ-атрибутов. Идея повзаимствована из рендереров ХТМЛ-я наподобии Спарка.
Так вот хочется обсудить синтаксис для встроенных в ХМЛ конструкций управляющих логикой генерации.
Я набросал пример того что я хочу видеть в данном движке. Прошу поглядеть его и высказать свои мысли (что добавить, что плохо и т.п.)
def x = 1;
def y = 0;
def zs = [...];
def var = xml <#
<root>
<table when="x > 0">
<tr if="y == 0">
<td foreach="z in zs">$z</td>
</tr>
<tr else-if="y < 0"></tr>
<tr else="y > 0"></tr>
<if cond="y == 0">
<tag1></tag1>
<tag2></tag2>
<tag3></tag3>
</if>
<else-if cond="y > 0">
<tag2></tag2>
<tag3></tag3>
</else-if>
<else>
<tag3></tag3>
</else>
$(if (y == 0)
xml <#
<tag2></tag2>
<tag3></tag3>
#>
else if (y > 0)
xml <#
<tag2></tag2>
<tag3></tag3>
#>
else if (y > 0)
xml <# <tag3></tag3> #>
)
</table>
</root>
#>;
Особые проблемы возникли с дизайном множественного if-а (позволяющего включить несколько тегов на основании некоторого логического условия). В конце этого примера я привел вариант основанный на теге <if> (который сам не включается в результирующих ХМЛ) и на базе обычного сплайса (здесь код приведен по месту, но конечно же он может быть вынесен во вне ХМЛ-цитаты, так что она будет выглядеть приличнее).
Насколько такой подход (с использованием управляющих тегов аля XSLT) приемлем?
Ну, и вообще, какие есть мысли по этому поводу?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну, и вообще, какие есть мысли по этому поводу?
По поводу придумать какой-нибудь новый синтаксис — это запросто
Мне кажется, лучше всего максимально использовать существующую спецификацию XML-литералов в Visual Basic'е:
По крайней мере, у многих уже есть трехлетний опыт работы с таким синтаксисом.
(ясно, что не все надо копировать один в один — например, в Nemerle традиционно используются $()-выражения для подстановки кода в разметку, а не скобки <% %>, как в VB)
Здравствуйте, VladD2, Вы писали:
VD>Насколько такой подход (с использованием управляющих тегов аля XSLT) приемлем?
Такой подход не очень хорош, потому что тот же тег if используется в в том же XSLT, в результате XLST будет выглядеть как чудовище, сложенное из эскейп-последовательностей.
Спарк выкручивался, потому что в HTML есть конкретный набор тегов. XML — в первую очередь расширяемый, eXtensible, язык, поэтому конфликты имен очень вероятны. Неймспейсы, как в XAML, не помогут, потому что мы должны уметь генерировать любой XML. Если мы, например, возьмем XML-префикс <n:...>, то не сможем легко генерировать XML для какого-то проекта, найденного в Гугле.
Мне кажется, все не-литералы лучше всего оформлять синтаксисом, который сам не является XML. Сделать это несложно: добавить куда-нибудь знак доллара или собачки, или восклицательный, или еще чего-нибудь.
Здравствуйте, catbert, Вы писали:
C>Мне кажется, лучше всего максимально использовать существующую спецификацию XML-литералов в Visual Basic'е:
В принципе все получается похоже на васик за исключением тех самых сплайсов которые действительно реализованы через $, так как это для немерла более традиционный путь. Кроме того будет поддерживаться и ..$ для списков.
Кроме идеи декларировать пространства имен (о чем я так же думал), я пока ничего интересного не увидел. В прочем я не пользуюсь васиком, так что просто могу чего-то не заметить. Если в васиковсокой реализации есть интересные решения, то просьба указать на них.
Так же прошу указать на то что у в моем дизайне отличается от васиковского (ну, кроме идеи встроенных ХМЛ-конструкций генерации ХМЛ-я).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, catbert, Вы писали:
C>Мне кажется, все не-литералы лучше всего оформлять синтаксисом, который сам не является XML. Сделать это несложно: добавить куда-нибудь знак доллара или собачки, или восклицательный, или еще чего-нибудь.
Проблема в том, что этот синтаксис будет конфликтовать с обычным текстом размещаемым внутри текста. В прочем, сплайсы уже требуют чтобы $-ы были "закрыты" каким-то образом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Проблема в том, что этот синтаксис будет конфликтовать с обычным текстом размещаемым внутри текста. В прочем, сплайсы уже требуют чтобы $-ы были "закрыты" каким-то образом.
Вот правила для названий тегов (отсюда):
* Names can contain letters, numbers, and other characters
* Names cannot start with a number or punctuation character
* Names cannot start with the letters xml (or XML, or Xml, etc)
* Names cannot contain spaces
Здравствуйте, VladD2, Вы писали:
VD>В принципе все получается похоже на васик за исключением тех самых сплайсов которые действительно реализованы через $, так как это для немерла более традиционный путь. Кроме того будет поддерживаться и ..$ для списков.
Ну, я сначала ответ написал, а потом уже вопрос написал Синтаксис очень похож на бейсиковский. Ну, спецификацию все равно можно использовать, если будут возникать мелкие проблемы с синтаксисом.
Из идей бейсика я не увидел неймспейсов вообще (они нужны) и использования XML-Axis в стиле:
document.<someElement>.@someAttribute.Value = 15
Конечно, у XmlAst немного другие цели, чем у бейсиковых литералов, поэтому XML-Axis вряд ли стоит реализовать.
VD>Так же прошу указать на то что у в моем дизайне отличается от васиковского (ну, кроме идеи встроенных ХМЛ-конструкций генерации ХМЛ-я).
В дизайне разницы я не уловил. В реализации, конечно, будет не хватать интелисенса на основе XSD.
Здравствуйте, catbert, Вы писали:
C>Из идей бейсика я не увидел неймспейсов вообще (они нужны)
Пространства имен я пока упустил для простоты. Они конечно же тоже планируются.
Единственный вопрос с ними — это где и как задавать короткие имена для них. В васике для этого используется глобальный импорт со специализированным синтаксисом. Немерле в текущей версии не так крут чтобы менять синтаксис using-а. Единственное что приходит в голову — это использовать глобальные атрибуты. Правда при этом имена будут глобальны для проекта, а не для файла (как в васике).
C>и использования XML-Axis в стиле:
C>
C>Конечно, у XmlAst немного другие цели, чем у бейсиковых литералов,
Цели в общем-то похожие. Я только хочу сделать несколько более мощную вещь позволяющую сильнее упростить генерацию ХМЛ-я.
C>поэтому XML-Axis вряд ли стоит реализовать.
А что там придумали? Я видимо не в курсе.
VD>>Так же прошу указать на то что у в моем дизайне отличается от васиковского (ну, кроме идеи встроенных ХМЛ-конструкций генерации ХМЛ-я).
C>В дизайне разницы я не уловил. В реализации, конечно, будет не хватать интелисенса на основе XSD.
А в васике это работает? Интересно как конкретно IDE-васика узнает о том какой XSD нужно применять?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Особые проблемы возникли с дизайном множественного if-а (позволяющего включить несколько тегов на основании некоторого логического условия). В конце этого примера я привел вариант основанный на теге <if> (который сам не включается в результирующих ХМЛ) и на базе обычного сплайса (здесь код приведен по месту, но конечно же он может быть вынесен во вне ХМЛ-цитаты, так что она будет выглядеть приличнее).
Можно любой синтаксис не валидный для ХМЛ.
Например так:
Поглядел... Это обычный АСП.НЭТ только с чуть измененным синтаксисом.
Единственное что в нем добавлено (и то вроде как пока нет) — это возможность выделять код в отдельные методы (@helper-ы). Для АСП наличие этих хэлперов конечно огромный шаг, но по сути ничего нового в данном движке нет.
Так что я совершенно не понимаю твоего восторга в его отношении.
Что касается ХМЛ-литералов, то это в общем-то не движок рендеренга. Я их спроектировал так, чтобы на базе парсера входящего в состав ХМЛ-литералов можно было сделать в том числе и движок рендеренга, но сами ХМЛ-литералы — это всего лишь удобный инструмент для конструирования ХМЛ-я в риложениях (надстройка над XLinq).
Подумав немного я решил вообще отказаться от полноценных if-ов и других управляющих констуркций.
Все что убдет в ХМЛ-литералах — это foreach в стиле Спарка и условное включение тегов, опять же аля-спарк. Примеры:
<div>
<b $when (condition)>$bar</b> <!-- срендерится только если condition == true -->
</div>
<div>
<b $if (x == 0) >$bar</b> <!-- срендерится только если x == 0 -->
<b $else if (x > 0)>$bar</b> <!-- срендерится только если x > 0 -->
<b $else >$bar</b> <!-- срендерится только если x < 0 -->
</div>
<ul>
<li $foreach (item in items)>$item</li>
</ul>
Думаю, что это дело покрое процентов 70 случаев когда нужно динамически генерировать подэлементы. Для остальных случаев можно будет использовать сплайсы "$" для включения выражений возвращающих одиночные элементы или текст и "..$" для вкючения выражений возвращающих списки.
Z>Кстати, в связи с его выходом все актуальнее становится версия немерла под 4.0 и 2010 студию.
Оно и само по себе актуально. Компилятор (вроде бы) работает на 4-ом фрэймворке. А вот перевод интеграции — это весьма объемная задача. Неизвесно сколько кода придется перписать чтобы перевести его. В новой студии многое переписано, так что за пару дней это дело не перевесит.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Поглядел... Это обычный АСП.НЭТ только с чуть измененным синтаксисом.
VD>Единственное что в нем добавлено (и то вроде как пока нет) — это возможность выделять код в отдельные методы (@helper-ы). Для АСП наличие этих хэлперов конечно огромный шаг, но по сути ничего нового в данном движке нет.
Эти хелперы я реализовал для спарка, дело не в них, их тоже можно эмулировать на старом asp.net. Я бы назвал этот движок спарком от майкрософта. Еще добавлены нормальные секции в лейауте, по типу спарка. Но самое главное, выброшен визуальный мусор асп.нет, наконец все стало читабельно.
VD>Так что я совершенно не понимаю твоего восторга в его отношении.
Особых восторгов нет, но это фактически официальный спарк, т.к. автор спарка работает в этой команде. Т.е. будет нормальная поддержка интелисенса, осталось только понять, сложность добавления нового языка.
VD>Подумав немного я решил вообще отказаться от полноценных if-ов и других управляющих констуркций.
Зря, имхо. Управляющий if еще можно эмулировать копипастом, a foreach нескольких тегов придется выносить. Неужели сложно реализовать
<$foreach (v in list)>
...
</$foreach>
VD>Оно и само по себе актуально. Компилятор (вроде бы) работает на 4-ом фрэймворке. А вот перевод интеграции — это весьма объемная задача. Неизвесно сколько кода придется перписать чтобы перевести его. В новой студии многое переписано, так что за пару дней это дело не перевесит.
Рано или поздно это сделать придется. В новой студии вроде бы все сделали более человечно, так что возможно не все так плохо, со всякими дизайнерами конечно проблема, но я бы на них забил.
Здравствуйте, Ziaw, Вы писали:
Z>Но самое главное, выброшен визуальный мусор асп.нет, наконец все стало читабельно.
Это конечно меняет дело. Когда дерьмо посыпают мишурой, оно конечно же начинает пахнуть совершенно иначе.
Z>Особых восторгов нет, но это фактически официальный спарк, т.к.
Мне от этой официальности ни горячо, ни холодно.
Z> автор спарка работает в этой команде. Т.е. будет нормальная поддержка интелисенса, осталось только понять, сложность добавления нового языка.
Пусть этот автор для начала хотя бы что-то из спарка прикрутит. А то замена одних финтифлюшек на другие не меняет общего состояния унылого дерма.
VD>>Подумав немного я решил вообще отказаться от полноценных if-ов и других управляющих констуркций.
Z>Зря, имхо. Управляющий if еще можно эмулировать копипастом, a foreach нескольких тегов придется выносить.
Люди делающие что-то копи-пэстом меня вообще не интересуют. Индуса только могила исправит.
Если кому-то нужно оперировать с множеством тегов, то их или нужно поместить в неких общий тег, или нужно произвести декомпозицию вынеся формирование этот самых тегов в отдельную операцию (функцию).
Встраивание полноценных языков внутрь литерала — это все же плохая идея. Использование для управляющих конструкций тегов (вроде <if ...>) еще худшая идея. Они будут сливаться с обычными тегами.
В конце концов добавить что-то всегда будет можно. Ведь добавить, не удалить.
Z> Неужели сложно реализовать Z>
Z><$foreach (v in list)>
Z> ...
Z></$foreach>
Z>
Не то чтобы сложно, но это мало чем будет отличаться от:
..$(lst.Map(xml <# ... #>))
Z>Рано или поздно это сделать придется. В новой студии вроде бы все сделали более человечно, так что возможно не все так плохо, со всякими дизайнерами конечно проблема, но я бы на них забил.
С дизайнерами как раз проблем особых быть не должно, а вот с разными смарт-тегами, редактором кода и т.п. очень даже будут (это там все полностью переписано).
Кстати, если есть время можешь сам попробовать. Если даже не получится, то хотя бы оценишь какие есть трудности.
Кстати, новая студия работает значительно медленнее чем старая и при этом мало что дает для немерла. Большую ценность имеет 4-ый фрэймворк.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
) работаю над созданием макроса xml-литерал. 
