А default options можно ли как нибудь запомнить (например всегда передавать заголовок для аутентификации) и использовать для всех последующих запросов?
Такой способ, кстати, еще хорошо подходит для отображения нескольких однородных таблиц. Таблицы получаются с одинаковыми ширинами столбцов, аккуратны и визуально воспринимаются лучше.
Все верно, можно и так.
Сейчас в вашем примере эти два заголовка визуально, скорее, имеют одинаковый вес, чем существенно разный.
Сравните h1 и h6 в html представлении (конечно, все зависит от конкретных каскадных стилей) и вы поймете, о чем я.
Отлично! Тогда все должны это использовать, чтобы читалось и интуитивно интерпретировалось одинаково.
Но, к сожалению, все не будут так делать и, к сожалению, проблема h3-h6 все равно остается.
Единственным решением, на мой взгляд, придумать новый способ указания заголовков (//////// or ;;;;;;;;;;; or :::::::::: or .........), но это уже будет совсем не markdown.
Ну, Нам, например, неприятно. Мы, как старовер, считаю, что «Мы», обращённое к одному человеку должно быть не таким, как «мы», обращённое к нескольким. И посему должно выделяться заглавной буквой :)
Как бы вы реализовывали большую форму 10+ контролов, где эти контролы взаимодействуют (например, включают вылючают др друга)?
Как бы вы (с)делали валидацию такой формы?
И наконец как бы собрали данные с этой формы?
На односложном jquery с селекторами (аля $('.email').val()) реализация подобных форм (и интерфейсов вообще) резко превращается в лапшу…
Можно сделать навигацию как в sublime2 (document map) и подсвечивать там текущую позицию, а при перемотке показывать «обычным строчным» способом текст.
Магия магией погоняет.
Было засилье инстанцовых методов бизнес логики.
Стало процедурно-статическое раздолье в моделях. Создал статические метод — вызываешь его инстацово, да еще и без поддержки ИДЕ.
Почему разработчики так хотят отделить мух от котлет, но, как мне кажется, у них это получилось плохо?! Почему бы просто не разделить букву М в MVC на две составляющие — данные и сервисные методы: Post и PostQuery. В последний поместить все угодные методы byCreator, removed, piblished и тд.
А в целом команда Yii молодцы :) очень много хороших, на мой взгляд, решений и улучшений.
Сейчас в вашем примере эти два заголовка визуально, скорее, имеют одинаковый вес, чем существенно разный.
Сравните h1 и h6 в html представлении (конечно, все зависит от конкретных каскадных стилей) и вы поймете, о чем я.
Но, к сожалению, все не будут так делать и, к сожалению, проблема h3-h6 все равно остается.
Единственным решением, на мой взгляд, придумать новый способ указания заголовков (//////// or ;;;;;;;;;;; or :::::::::: or .........), но это уже будет совсем не markdown.
Сравните:
# Document Titleи
###### Sub x 6 titleЧто выделяется лучше? Правильно, второй вариант. Хотя в html виде первый вариант — это h1-заголовок, а второй — h6-заголовок.
Попробую снова…
Как бы вы реализовывали большую форму 10+ контролов, где эти контролы взаимодействуют (например, включают вылючают др друга)?
Как бы вы (с)делали валидацию такой формы?
И наконец как бы собрали данные с этой формы?
На односложном jquery с селекторами (аля $('.email').val()) реализация подобных форм (и интерфейсов вообще) резко превращается в лапшу…
Вся магия в одной строке:
with (DATA) return eval(value.substring(1));все остальное — обвесы…
— Вижу…
— А фичи-то нету
Было засилье инстанцовых методов бизнес логики.
Стало процедурно-статическое раздолье в моделях. Создал статические метод — вызываешь его инстацово, да еще и без поддержки ИДЕ.
Почему разработчики так хотят отделить мух от котлет, но, как мне кажется, у них это получилось плохо?! Почему бы просто не разделить букву М в MVC на две составляющие — данные и сервисные методы: Post и PostQuery. В последний поместить все угодные методы byCreator, removed, piblished и тд.
А в целом команда Yii молодцы :) очень много хороших, на мой взгляд, решений и улучшений.