to post messages and comments.

← All posts tagged хуита

В продолжение к #2836047
На самом деле, HandlerT внутри использует `Loc -> LogSource -> LogLevel -> LogStr -> IO ()` который конструируется из `Logger` (который логирует только в файл), который берется из site, через метод тайпкласса `Yesod` (почему было не передать логер напрямую запускалке `warp`, я так и не понял). При этом, указанная функция логирования конструируется через метод тайпкласса Yesod `messageLoggerSource :: site -> Logger -> Loc -> LogSource -> LogLevel -> LogStr -> IO ()`. То есть, если хочешь логировать другим способом, тебе надо тупо игнорировать `Logger` (но при этом все равно его создавать и передавать) в этом методе, и использовать другой логер, хранящийся в твоем site.
Вангую, что messageLoggerSource был добавлен позже, как раз ради возможности логировать не через LoggerSet. Вместо того, чтобы поправить сам Logger.
Столько говна на пустом месте. Снойман, охуевший ублюдок, что ты делаешь, прекрати!

Гуглореклама на жуике показывала банер "умер ли христос?". Я нажал на крестик, причиной отказа указал "непристойное содержание", в ответ получил:
"Мы проверим это объявление и сделаем все возможное для повышения качества рекламы"
Наконец то мы узнаем, умер ли на самом деле христос, или, что бога нет, на пример.

When a URI appears in a
protocol element, the character encoding is defined by that protocol;
without such a definition, a URI is assumed to be in the same
character encoding as the surrounding text.
И больше в RFC-3986 по этому поводу ничего толком не сказано. Это в связи с моим вчерашним спором. Выходит, что голый URI — это все таки байты. Вот же говно. Хотя, не понятно, что мешает в йесоде парсить заголовки, определять кодировку и преобразовать-таки байтоговно в текст.

Есть у меня ТЗ, в котором есть форма для редактирования объектов А, у которых есть несколько объектов Б, в каждого из которых может быть по нескольку объектов класса В и Г. Все это добро мне надо редактировать на одной странице и в одной форме.
Расположение элементов сверху вниз:
Поля объекта а1
кнопка "добавить объект Б"
поля объекта б1
   кнопка "добавить объект Г"
   поля объекта г1 
   поля объекта г2 
   ........
поля объекта б2 
    кнопка добавить объект В
    поля объекта в1 
    поля объекта в2
    ...........
...........
поля объекта а1
То есть, объекты б1 и б2 редактируются в рамках объекта `а`, а объекты г1, г2, в1 и в2 редактируются в рамках объектов б1 и б2, какбы логически им принадлежат.
Я понимаю, что подобные ебанистические формы - это полная хуита, но таково ТЗ. 
Если бы в html можно было бы вложенные формы, то вопрос бы не возник, но сейчас я занимаюсь тем, что изобретаю названия полей в таком духе: "object_a[object_b_1][field_name]" или "object_a[object_b_1][object_c_1][field_name]"  а потом, на стороне сервера парсю названия и заполняю базу в рамках одного запроса, что является полнейшим говнокодом и уебанством.
Вопрос: как такое лучше сделать вообще, включая варианты с AngularJS? Думается, что делать это все на клиенте будет проще, а на сервере оставить человеческий REST API, но не превратится ли это в ад на клиенте?