Dropdown не нужен. Логин\e-mail поля взаимозаменяемые. Т.е. поля должно быть два, но первое называется «Input login OR e-mail» (где-то я это уже видел) второе, соответственно обычный пароль.
Для исключения коллизий можно просто запретить в никнейме вводить цобаку — это достаточно логично.
Я вообще целиком за именно такую систему, т.к. мой txt файл с логинами паролями и мейлами для сайтов уже превышает 100 строк :)
Пока что получается очень хорошо :) Лично я бы с удовольствием послушал обещанные вырезки из лекций про деревья: Р
Спасибо за видео и наводку на книгу! :)
Если не лукавить — никак.
При правильной иерархии такое навряд ли случается. Все базовые настройки правятся руками но таких могу назвать только две: какой-нибудь path и параметры коннекта к базе. Все остальное — уже производное от них и такие конфиги входят в сборку.
По-крайне мере в моем случае.
Если честно, не задумывался раньше какая это все-таки проблема: локальная разработка и «терминальный» билд :)
У нас для сборки Java приложения, работающего на Jboss'e используется Bamboo — он собирает проект, беря его из репозитория. При этом файлы конфигурации в билд не входят — они свои для каждого участника проекта ( и для стенда на котором проект в итоге собирается).
Те факты, собранные в этой статье, собственно, обсуждаются уже давно. Я столкнулся с явлением «автогенерации» html и js как ассемблерного кода в JSF и IceFaces (вроде ruby Rails в том же направлении работает?).
И получается так, что данные форматы\спецификации (html и js) являются asm'ом в Web'e на данное время. Но лично я об это сожалею и очень был бы рад за модификацию технологий(т.н. интенсивный прогресс а не экстенсивный). Т.к. подобное текущие использование автогенерации просто огорчает, хоть и позволяет абстрагироваться от многих неприятных мелочей. Да и, имхо, html слишком неповоротлив чтобы стать ассемблером для Web-приложений. А asm нельзя недооценивать, даже программируя на чем-то «предельно высокоуровневом» :)
И, могу ошибаться, вроде это есть нормальные life-cycle для приложения: производить refactoring время от времени, как в области кода, так и документации к приложению. Причины, почему эта ситуация нормальна — более глубокая проблема.
Вряд ли вас это успокоит, но, к сожалению, подобные проблемы характерны далеко не «just for fun» проектов, а очень даже для коммерческих: спроектированных и проданных.
Для исключения коллизий можно просто запретить в никнейме вводить цобаку — это достаточно логично.
Я вообще целиком за именно такую систему, т.к. мой txt файл с логинами паролями и мейлами для сайтов уже превышает 100 строк :)
Спасибо за видео и наводку на книгу! :)
При правильной иерархии такое навряд ли случается. Все базовые настройки правятся руками но таких могу назвать только две: какой-нибудь path и параметры коннекта к базе. Все остальное — уже производное от них и такие конфиги входят в сборку.
По-крайне мере в моем случае.
У нас для сборки Java приложения, работающего на Jboss'e используется Bamboo — он собирает проект, беря его из репозитория. При этом файлы конфигурации в билд не входят — они свои для каждого участника проекта ( и для стенда на котором проект в итоге собирается).
И получается так, что данные форматы\спецификации (html и js) являются asm'ом в Web'e на данное время. Но лично я об это сожалею и очень был бы рад за модификацию технологий(т.н. интенсивный прогресс а не экстенсивный). Т.к. подобное текущие использование автогенерации просто огорчает, хоть и позволяет абстрагироваться от многих неприятных мелочей. Да и, имхо, html слишком неповоротлив чтобы стать ассемблером для Web-приложений. А asm нельзя недооценивать, даже программируя на чем-то «предельно высокоуровневом» :)
А по сути — к такому отношению к заказчику приходит каждый, но со временем. Потому что по-другому не получается…
Вряд ли вас это успокоит, но, к сожалению, подобные проблемы характерны далеко не «just for fun» проектов, а очень даже для коммерческих: спроектированных и проданных.