Комментарии 21
Спасибо, буду смотреть
Спасибо! Отличная статья!=)
Объясните пожалуйста, почему в России так часто искажают название данного языка (Java), в то время как носители языка, к которым принадлежат и люди, стоявшие у истоков данной технологии произносят это как «Джава»?
Вам режет слух?
Мне его режет, когда произносят немецкие названия: к примеру Рейн вместо Райн, ГанновЕр вместо ХаннОфер, Гейдельберг вместо Хайдельберг. Так же режет слух, когда немцы говорят Москау вместо Москва. Тут такое дело… изменять его нет смысла. Или вы говорите про остров Ява тоже Джава?
На самом деле дискуссия тут бесполезна и все упирается во вкус и привычку. Я привык произносить по немецки и по рускки Ява по отношению к языку программирования и острову.
Мне его режет, когда произносят немецкие названия: к примеру Рейн вместо Райн, ГанновЕр вместо ХаннОфер, Гейдельберг вместо Хайдельберг. Так же режет слух, когда немцы говорят Москау вместо Москва. Тут такое дело… изменять его нет смысла. Или вы говорите про остров Ява тоже Джава?
На самом деле дискуссия тут бесполезна и все упирается во вкус и привычку. Я привык произносить по немецки и по рускки Ява по отношению к языку программирования и острову.
Это конечно режет слух, но дело не в этом. Зачем делать так, чтоб иностранные коллеги вас не понимали? Зачем придумать что-то новое, когда есть устоявшийся во всем мире термин? Ладно бы Вы его придумали, но ведь люди придумавшие термин однозначно называют это по другому? Вам сложно произнести это правильно, хотя бы ради уважения к создателям? Ну давайте дотнет величать каким-нибудь тэнетом — мы же русские у нас все по другому и мы будем карявить термины…
люди в теме понимают с пол-пинка:)
мне кажется вы немного преувиличивате проблему, которой на самом деле нет. С иностранными коллегами идет конверсация на всем понятном языке, к примеру на английском, все термины соответственно применяются относительно к используемому языку.
мне кажется вы немного преувиличивате проблему, которой на самом деле нет. С иностранными коллегами идет конверсация на всем понятном языке, к примеру на английском, все термины соответственно применяются относительно к используемому языку.
В статьях и более менее официальных документах, переводить в русские буквы такие слова, как MySQL, Java и т.п. является плохим тоном. В камментах же это роли не играет. А на счёт произношения Java, мне больше нравится оригинальный вариант [джава], он более сочный, яркий и соответствует тому, как большинство программистов мира его произносит — SAMPA: /''dZA:va/.
плохим тоном (вернее доказательством незрелости) является доказывание с пеной у рта своих взглядов на определенные вещи, принятие этих взглядов как единственно правильные, а так же отторжение альтернатив.
Как пример старый баян, кто изображен на картинке, старая или молодая женщина?
Слово и название (имя собственное?) Ява не противит правилам русского языка и имеет право на существование. См. мой комментарий выше. Иначе все названия городов в русском языке (да и в других) надо поменять.
На этом дискуссию и флэйм предлагаю закрыть/перенести в другой топик и там насладиться развитием этой темы. Пожалуйста далее комментарии только по теме.
Как пример старый баян, кто изображен на картинке, старая или молодая женщина?
Слово и название (имя собственное?) Ява не противит правилам русского языка и имеет право на существование. См. мой комментарий выше. Иначе все названия городов в русском языке (да и в других) надо поменять.
На этом дискуссию и флэйм предлагаю закрыть/перенести в другой топик и там насладиться развитием этой темы. Пожалуйста далее комментарии только по теме.
Несущественно.
Как раз-таки Джава режет слух, а Ява — ахуительное слово!
Это все конечно хорошо, но в реальных предметных областях бывает очень и очень запутанная валидация. Например, одно поле зависит от другого поля или даже объекта, или несколько полей составляют одну ошибку, исправить которую можно изменив значение одного из полей.
ну так тут только знакомство со стандартом. На самом деле ограничения тоже можно довольно «легко» проверять и длля графов из объектов: для этого нужно использовать аннотацию @Valid:
при вызове validator.validate(myCustomer); автоматически будет валидироваться и объект класса Address.
Так же существиет возможность объединения ограничений по группам и назначения им собственных валидаторов, которые, в свою очередь могут при проверке учитывать и зависимости между полями.
import javax.validation.Valid;
public class Customer {
...
@Valid
Address adress;
...
}
* This source code was highlighted with Source Code Highlighter.при вызове validator.validate(myCustomer); автоматически будет валидироваться и объект класса Address.
Так же существиет возможность объединения ограничений по группам и назначения им собственных валидаторов, которые, в свою очередь могут при проверке учитывать и зависимости между полями.
А как же i18n? Или для каждого языка свой bean создавать?
Вопроса не совсем понял, но попробую угадать
Речь идет о интернализации сообщений?
На самом деле все очень просто. Создается ResourceBundle, в нем прописываются properties, к примеру
//ValidationMessages.properties
User.firstname.notnull=Имя должно быть задано
В аннотации прописывается message="{User.firstname.notnull}" и если ValidationMessages.properties находится в корне classpath'а, то {User.firstname.notnull} заменяется на Имя должно быть задано. Разумеется для каждой локали могут быть дефинированы свои ValidationMessages, они будут загружаться автоматически.
Разумеется, ResourceBundle может называться как угодно и находиться где угодно, только в этом случае необходимо конфигурировать фэктори. Но это уже другая история:)
P.S. лично мое мнение таково, что слово Bean в названии стандарта несколько неправильно, так как валидация может применятся в любом POJO.
Речь идет о интернализации сообщений?
На самом деле все очень просто. Создается ResourceBundle, в нем прописываются properties, к примеру
//ValidationMessages.properties
User.firstname.notnull=Имя должно быть задано
В аннотации прописывается message="{User.firstname.notnull}" и если ValidationMessages.properties находится в корне classpath'а, то {User.firstname.notnull} заменяется на Имя должно быть задано. Разумеется для каждой локали могут быть дефинированы свои ValidationMessages, они будут загружаться автоматически.
Разумеется, ResourceBundle может называться как угодно и находиться где угодно, только в этом случае необходимо конфигурировать фэктори. Но это уже другая история:)
P.S. лично мое мнение таково, что слово Bean в названии стандарта несколько неправильно, так как валидация может применятся в любом POJO.
Для запуска кода нужен весь жирненький Hibernate или достаточно небольшого jar-ника? Спрашиваю потому, что у меня в проекте используется другая ORM, но данную возможность валидации хотелось бы иметь.
Сам Hibernate совсем не нужен. Валидация работает везде и независит от других библиотек или сервисов.
Требуется только validation-api-1.0.CR3.jar, hibernate-validator-4.0.0.Beta2.jar + библиотеки для логгера. Все вместе весит примерно 200-300 Кб и находится в lib дистрибуции по ссылке: https://www.hibernate.org/30.html, далее Hibernate Validator 4.0.0.
Требуется только validation-api-1.0.CR3.jar, hibernate-validator-4.0.0.Beta2.jar + библиотеки для логгера. Все вместе весит примерно 200-300 Кб и находится в lib дистрибуции по ссылке: https://www.hibernate.org/30.html, далее Hibernate Validator 4.0.0.
Можно ли использовать новый способ валидации в проектах, которые написаны с сипользованием Maven и как это сделать?
я думаю что это возможно, хотя мы сами maven к сожалению не используем, т.к. разрабатываем на OSGi/Equinox.
посмотрите в этих репозиториях:
посмотрите в этих репозиториях:
<repositories>
<repository>
<id>jboss</id>
<url>repository.jboss.com/maven2</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<repository>
<id>jboss-snapshot</id>
<url>snapshots.jboss.org/maven2</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
* This source code was highlighted with Source Code Highlighter.Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Знакомство с Bean Validation API