эмм, я знаю что angular сам по себе просто как клиентское приложение может управлять путями (ng-route), зачем примешивать сюда сервер, делаешь например субдомен с api (api.domain.com), а приложение angular просто как развернутую статику в корне (domain.com) например с помощью yeoman (generator-angular), но это подходит лишь если у тебя вся обработка планируется на клиенте (только для современных браузеров, о ишаке вообще молчу). Но если ты любишь извращаться то sails.config.routes в помощь. Но sails не чистый express, тут много удобных тонкостей которые сделают из приложения Т-90.
Я когда изучал Angular в их туториале, я просто настроил бэкенд на json API из ajax запросов (простой вариант), тогда получается что ты обрабатываешь непосредственно API. Остальное дело техники history api.)
статья рассчитана не просто как сборник, а как справочник небольших и практических советов, по использованию тех или иных возможностей Sails, которые новичок сможет использовать не обращая внимания на какие-либо «особые» тонкости. Бывает, когда некоторые очевидные вещи нельзя понять сразу (с чем и сталкиваются новички), например когда я начинал изучение Sails я не мог простейшую выборку в waterline сделать. Статья про интеграцию Passport которую вы привели, врядле будет простой в понимании для тех кто захочет ее использовать — лично на мой взгляд она хороша, но не обладает гибкостью в понимании. В тот момент когда была написана статья уже вышел генератор sails-generate-auth, статья же оказывалась сложной в понимании — даже более чем документация как использовать тот генератор. А коронные фишки Sails и их использование — я обещаю написать в 3 части, обещаю что статья будет не сухой и маленькой, а более полной и интересной
Если бы я все новые фичи вместе собрал в одну статью, она бы получилась бы очень большой, я разбиваю на кусочки — и стараюсь написать так чтобы было понятно человеку который может даже о Sails впервые услышал. Про ассоциации или как просто и удобно пользоваться подписями и сокетами, и как работать с другими вкусностями я расскажу в следующих частях. А выкладываю в первых частях то что полегче — что может понять даже новичок. Самое интересное я оставил для последних частей — про запас, для чуть более искушенных пользователей
видимо я слишком сложно оценил проблему, зачем делать столько телодвижений. jQuery.Validator, простая обработка поля на клиенте. Даже серверная реализация не нужна — хватит простого плагина. А я думал что вы имеете ввиду глобальную обработку объектов логирования ).
Если я правильно понял вы имеете ввиду ошибку которую например выдает waterline если есть несоответствие каких либо правил из атрибутов. Если это так — то возвращаеться примерно такой объект.
{
"error": "E_VALIDATION",
"status": 400,
"summary": "1 attribute is invalid",
"model": "Test",
"invalidAttributes": {
"lalala": [
{
"rule": "string",
"message": "`undefined` should be a string (instead of \"null\", which is a object)"
},
{
"rule": "required",
"message": "\"required\" validation rule failed for input: null"
}
]
}
}
Я конечно плохо понимаю что ты хочешь сделать, но если ты хочешь в корне изменить текст то тебе придется ковырять в исходниках и там переводить места где происходит генерация объекта ошибок, но это занятие лишнее и неблагодарное. Если тебе просто удобно получать логи в разобранном виде и на русском — советую просто написать небольшой парсер для этого дела. Лично я для похожей ситуации (удобное ведения логов) использовал xml. за более удобную структуру (Имхо). В особых случаях можно использовать lodash в нем можно разбирать сложные структуры (не для простых отчетов об ошибках). Возможно я просто неправильно понял вопрос, но это те решения которые можно использовать. Если же тебе просто не нравиться читать отчеты на английском, то не повод ли это просто лучше выучить английский?
Можете пожалуйста поделится причиной почему нужно включать именно «coffee-script/register»? Если это связано с ошибкой при развертывании приложения на forever — то я этой ошибки не заметил, хотя использую кофе 1.7.1
Я конечно плохо понимаю что ты хочешь сделать, но если ты хочешь в корне изменить текст то тебе придется ковырять в исходниках и там переводить места где происходит генерация объекта ошибок, но это занятие лишнее и неблагодарное. Если тебе просто удобно получать логи в разобранном виде и на русском — советую просто написать небольшой парсер для этого дела. Лично я для похожей ситуации (удобное ведения логов) использовал xml. за более удобную структуру (Имхо). В особых случаях можно использовать lodash в нем можно разбирать сложные структуры (не для простых отчетов об ошибках). Возможно я просто неправильно понял вопрос, но это те решения которые можно использовать. Если же тебе просто не нравиться читать отчеты на английском, то не повод ли это просто лучше выучить английский?