Спасибо за ваш вопрос, как уже упоминалось ранее, в большинстве случаев это решение принимается командой, с которой вы работаете. Исходя из моего личного опыта, я могу только объяснить вам, почему мы решили использовать определение промежуточного программного обеспечения в файле маршрутов вместо контроллера.
В больших приложениях есть много случаев дюжины контроллеров. С учетом вышесказанного могут быть случаи, когда вам придется изменить какое-либо имя промежуточного программного обеспечения. Если вы определите его в группе маршрутов, вам придется изменить только одну строку кода, но если вы определите это в конструкторе, вам придется перейти к каждому контроллеру и изменить его.
Некоторые компании используют контроллеры, чтобы вводить классы в него. Там может быть огромное количество инъекций и присваивания классов в самом конструкторе. Вот почему определение критических проверок не должно происходить на этом уровне кода.
Я предполагаю Вам решать для определения семантики, но по-моему:
, А не список определения, связанные с формой свойства должны использоваться.
<form>
<label for="fullname">Full Name:</label>
<input type="text" name="fullname" id="fullname">
<label for="email">Email Address:</label>
<input type="text" name="email" id="email">
</form>
"для" атрибута в < label> тег должен сослаться на "идентификационный" атрибут < input> тег. Обратите внимание, что то, когда маркировки связаны с полями, нажав маркировку, поместит связанное поле в фокус.
можно также использовать теги как < fieldset> к кластерным разделам формы вместе и < legend> озаглавливать fieldset.
Я успешно использовал технику, обрисованную в общих чертах в эта статья несколько раз.
я соглашаюсь с sjstrutt, что необходимо использовать связанные с формой теги как label
и form
в Вас формы, но HTML, обрисованный в общих чертах в его примере, будет часто испытывать недостаток в некотором коде, который можно использовать как "рычаги" для моделирования формы с CSS.
В результате этого я разметка мои формы как это:
<form name="LoginForm" action="thispage">
<fieldset>
<legend>Form header</legend>
<ul>
<li>
<label for="UserName">Username: </label>
<input id="UserName" name="UserName" type="text" />
</li>
<li>
<label for="Password">Password: </label>
<input id="Password" name="Password" type="text" />
</li>
</ul>
</fieldset>
<fieldset class="buttons">
<input class="submit" type="submit" value="Login" />
</fieldset>
</form>
Этот подход оставляет меня с понятным набором тегов, который содержит достаточно рычагов для моделирования форм большим количеством различных способов.
Это - подмножество проблемы семантики по сравнению с форматированием. В списке определения говорится, каковы они, список связанных атрибутов ключа/значения, но не говорит, как отобразить его. Таблица говорит больше о расположении и как отобразить данные затем, каковы данные внутри. Это ограничивает, как список может быть отформатирован и путем чрезмерного определения формата и underspecifying, каково это.
HTML, исторически, путал семантику с форматированием. Теги шрифта и таблицы, являющиеся худшими примерами. Перемещение к CSS для форматирования и разделения большого чистого форматирования отмечает из восстановлений XHTML, несколько, разделения значения от форматирования. Путем распадения форматирующий в CSS можно отобразить тот же HTML, по-разному переформатировавший его для широкого браузера, маленького мобильного браузера, печати, простого текста, и т.д.
Для просвещения, посетить CSS Zen-Garden .
Списки определения имеют семантическое значение. Они для списка условий (< dt>) и их связанные определения (< dd>). Поэтому в этом случае < dl> изображает семантическое значение содержания более точно, чем таблица.
В этом случае маркировки и исходные данные Ваше семантическое значение, и они стоят самостоятельно.
Предполагают, что необходимо было считать веб-страницу, загрузиться слепому человеку. Вы не сказали бы "Хорошо, я имею список определений здесь. Первым термин является 'имя'". Вместо этого Вы, вероятно, сказали бы "Хорошо, что мы имеем форма здесь, и она похожа существует набор полей , первые вводят , , маркировал 'имя'".
Поэтому семантическая паутина важна. Это позволяет содержанию страницы представлять себя точно обоим людям и технологии. Например, существуют многие браузер плагины , что люди справки быстро заполняют веб-формы со своей стандартной информацией (имя, номер телефона, и т.д.). Они редко работают хорошо, если исходные данные не имеют связанных маркировок.
Hope, которая помогает.
Часть причины использования < dl> для повышения формы - то, что намного легче сделать необычные приемы расположения CSS с < dl>, чем < таблица>. Другая часть - то, что это лучше отражает семантику формы (список пар маркировки/поля), чем таблица была бы.
хорошо, ненависть таблицы является частью его также.
Иногда, список определения просто представляет информацию в способе, которым это желаемо, пока таблица не делает. Лично, я, вероятно, не использовал бы список определения для формы, если это не удовлетворяет стилю сайта.
Списки определений почти никогда не используются, потому что, говоря семантически, они редко появляются в Интернете.
В вашем случае был опубликован правильный код:
<form>
<label for="fullname">Full Name:</label>
<input type="text" name="fullname" id="fullname">
<label for="email">Email Address:</label>
<input type="text" name="email" id="email">
</form>
Вы создаете форму с входными данными и ярлыки для указанных входных данных, вы не устанавливаете список слов и не определяете их.
Если вы делаете какой-то раздел справки, тогда уместны списки определений, например:
<dl>
<dt>HTML</dt>
<dd>Hypertext Markup Language</dd>
<dt>CSS</dt>
<dd>Cascade Stylesheets</dd>
<dt>PHP</dt>
<dd>Hypertext Preprocessor</dd>
</dl>
Практически все формы являются табличными. Вы когда-нибудь видели не табличную форму? В рекомендациях, которые я прочитал, предлагается использовать тег table для табличного представления, и именно для этого нужны формы, календари и электронные таблицы. А теперь вместо таблиц используют DD и DT? Куда идет Интернет ?! :)
Использование dl
dt
, dd
для форм - это еще один способ структурировать формы, наряду с ul
li
, ] div
и таблица
. Вы всегда можете поместить метку
в dt
. Таким образом вы сохраните метку элемента формы на месте.
<form action="/login" method="post">
<dl>
<dt><label for="login">Login</label></dt>
<dd><input type="text" name="login" id="login"/></dd>
<dt><label for="password">Password</label></dt>
<dd><input type="password" name="password" id="password"/></dd>
<dd><input type="submit" value="Add"/></dd>
</dl>
</form>