почему секция userpic не включена в author?

а, понял. интересно что народ скажет по этому поводу

почему секция userpic не включена в author?

так удобнее было с точки зрения реализации на сервере. Это важно?

"processedMessage": "<div class=\"none\">&gt;&gt;-----Цитата----&gt;&gt;</div><div class=\"quote\"><p>На сколько это действительно необходимо чинить - я не знаю.<br></p></div><div class=\"none\">&lt;&lt;-----Цитата----&lt;&lt;</div><p>Нужно.</p>",

формат передачи форматирования (сори за каламбур) както слишком излишен

Это важно?

нет, я просто подумал что все что есть юзерово, должно быть при нем.

так удобнее было с точки зрения реализации на сервере

значит пока? будет так

это HTML из обработчика lorcode

а почему комментарии, которые есть ответами на стартовое сообщение не содержат секции reply?

Это я понял. но тем не менее мне он видится раздутым

offtop: test1; test2

зачем отдельная секция под editSummary? зачем в editSummary нужен editNick? неужели были случаи когда модер правил сообщение пользователя? или в будущем сие будет возможно/планируется? :)

и да,

"postdate": "2012-12-24T15:15:15.942+0000"

не самый лучший формат для обработки на клиенте.

ps: у меня все

упс, не все

комментарий

"title": ""

ответ

"reply": {
            "id": 8630346,
            "author": "ZuBB",
            "title": "комментарий",
            "postdate": "2012-12-24T15:08:05.073+0000",
            "samePage": true
        }

«title»: «комментарий»

нестыковочка ;)

еще я бы позвал Kalashnikov

offtop: this is a test.

offtop: this is a first part of test. please do not delete

second part of test. please do not delete

c title`ами какой то непорядок

    }, {
        "id": 8630554,
        "author": {
            "nick": "ZuBB",
            "stars": [true, true, true]
        },
        "processedMessage": "<p>offtop: this is a first part of test. please do not delete</p>",
        "reply": {
            "id": 8630452,
            "author": "ZuBB",
            "title": "комментарий",
            "postdate": "2012-12-24T15:32:14.751+0000",
            "samePage": true
        },
        "deletable": false,
        "editable": false,
        "deleted": false,
        "postdate": "2012-12-24T15:52:36.835+0000",
        "userpic": {
            "url": "/photos/51203:1317883068.png",
            "width": 107,
            "height": 150
        },
        "title": "offtop: this is a test."
    }, {
        "id": 8630557,
        "author": {
            "nick": "ZuBB",
            "stars": [true, true, true]
        },
        "processedMessage": "<p>second part of test. please do not delete</p>",
        "reply": {
            "id": 8630554,
            "author": "ZuBB",
            "title": "offtop: this is a test.",
            "postdate": "2012-12-24T15:52:36.835+0000",
            "samePage": true
        },
        "deletable": true,
        "editable": true,
        "deleted": false,
        "postdate": "2012-12-24T15:52:54.110+0000",
        "userpic": {
            "url": "/photos/51203:1317883068.png",
            "width": 107,
            "height": 150
        },
        "title": ""
    }],

ну все. это точно последнее. как минимум на сегодня

флаг deleted это хорошо. но я надеюсь есть способ получить список сообщений вместе с удаленными сообщениями?

Да, логику с title надо переделать

Технически такая возможность была сделана, но на практике не применялась. Надо будет убрать значение в случае когда автор исправлял

Крайне полезное начинание, так держать. (:

Джва года ждали

Отлично, просто превосходно.

Мне немного не нравятся форматы даты (имхо, юникстайм во все поля), звёзды каки-то странные (что с серыми например?), не проще передавать два числа? И в reply мне кажется достаточно лишь id сообщения, остальное забота клиента. Впрочем, я бы много чего оттуда вырезал. Но в целом мне нравится и я таки рад.

Кстати, запили поддержку If-Modified-Since.

Мне немного не нравятся форматы даты (имхо, юникстайм во все поля)

Вроде как это стандартный формат даты на новых версий JS и HTML5, так что должно быть удобно в использовании на клиенте

звёзды каки-то странные (что с серыми например?), не проще передавать два числа?

Серая звезда - false. Такой формат получился из-за желания впихнуть его в тупой шаблонизатор вроде Jade или Mustache в которых нет циклов по диапазону

кажется достаточно лишь id сообщения, остальное забота клиента

мне надо что-бы эта забота не приводила к куче мелких запросов - это плохо и для сервера, и для клиента

Кстати, запили поддержку If-Modified-Since.

По опыту поддержка If-M-S вызывает проблемы т.к. контент может меняться из-за разных внешних изменений (изменение количества звезд у пользователя, «перечеркивание» и т.п.) из-за чего выходят косяки (особенно из-за способностей броузеров сочетать If-M-S с докачкой). Так что наверное я не буду поддерживать это. Однако есть в планах добавить запрос вроде «получить комментарии после указанной даты» для реализации подгрузки новых комментов без перезагрузки страницы

Да это же как в xmpp! http://xmpp.org/extensions/xep-0082.html#sect-id143999

да, посмотрел он парсится на ура. но имхо «дешевле» передать unix time stamp нежели отформатированную относительно локали строку.

www.linux.org.ru/template/comment.jade

у меня браузер каракули показывает, указал utf-8 ok

Поправлю

А как на клиенте шаблон можно использовать? Пока нашёл только костыли которые прикручивают require и соответственно весь модуль к браузеру.

В доках есть что-то на жту тему, но я толком не понял:

Through the use of Jade's ./runtime.js you may utilize these pre-compiled templates on the client-side without Jade itself...

Ещё такую штуку нашёл для ноде.

А как на клиенте шаблон можно использовать? Пока нашёл только костыли которые прикручивают require и соответственно весь модуль к браузеру.

Почему бы не прикрутить весь модуль к браузеру?

По-моему это очень лишнее в юзерскрипте, тем более если каждый будет тащить свой модуль, может получиться несколько одновременно на странице. Ты же всё равно в своём коде насколько я понимаю планируешь использовать шаблонизатор? Так может оставить его где-нибудь в глобальном объекте чтоб из клиентских скриптов можно было дёргать?

Я толком не понял что делает require.js, но вроде оно не тащит весь модуль, а только скомпиленные шаблоны. Если так, то это по-моему идеальный вариант.

частично поправил

fixed

Пока есть только параметр ?page=N.

Посмотри ветку Ильдара «show_deleted», там реализована своя полноценная пагинация.

"author": {

    "nick": "hizel",
    "stars": [
        true,
        true,
        true,
        true,
        true
    ]

},

Эм... по-моему, так лучше:

"stars": {
   total: 5;
   active: 5;
}

А как звёзды клиент нарисует (и нарисует ли вообще) API не должно волновать.

    "stars": [
        true,
        true,
        true,
        true,
        true
    ]

А есть ли возможность погасить звезду в середине?

Мне немного не нравятся форматы даты (имхо, юникстайм во все поля),

присоединяюсь. Лучше всего unix timestamp в секундах, UTC. Клиент уже сам нарисует правильное время в зависимости от СВОЕГО часового пояса.

А есть ли возможность погасить звезду в середине?

а зачем? :)

Я предлагаю total/active, если что. Массив булевых значений сейчас уже реализован. Если действительно надо гасить звезду в начале/середине, тогда массив булеанов будет применим.

А как звёзды клиент нарисует (и нарисует ли вообще) API не должно волновать.

Клиенту с нормальным Я.П. не составит проблемы подсчитать сумму false/true, а для тупых так удобнее

присоединяюсь. Лучше всего unix timestamp в секундах, UTC. Клиент уже сам нарисует правильное время в зависимости от СВОЕГО часового пояса.

Текущая реализация скрипта поддержки часовых поясов успешно работает с ISO8601 из тега <time>

а для тупых так удобнее

эм... для тупых - это для кого? клиентов или их создателей?

Передавай тогда уже массив чисел, по дефолту 1 или 0. На будущее можно будет передавать, скажем, [1, 1, 1, 0.5, 0]. Типа, ползвезды посерело...

эм... для тупых - это для кого? клиентов или их создателей?

для шаблонизаторов вроде Jade или Mustache

одним местом чувствую, что неправильно подстраивать целое API под таких клиентов, а как словами рассказать - не знаю.
В целом, проблему понял. Если начну копать гугль в сторону правильного парсинга значений перечисленными шаблонизаторами, поменяешь массив на total/active, если раскопаю? Другими словами, тратить время на это или нуево?

Другими словами, тратить время на это или нуево?

Ну погляди, хотя я бы не стал тратить время. Решение с добавлением внешней функции за решение не считается, потому что хочется иметь как можно меньше внешних функций что-бы не усложнять написание клиентов

По-моему это очень лишнее в юзерскрипте, тем более если каждый будет тащить свой модуль, может получиться несколько одновременно на странице. Ты же всё равно в своём коде насколько я понимаю планируешь использовать шаблонизатор? Так может оставить его где-нибудь в глобальном объекте чтоб из клиентских скриптов можно было дёргать?

Да, шаблонизатор подключу как буду использовать на клиенте

Клиенту с нормальным Я.П. не составит проблемы подсчитать сумму false/true, а для тупых так удобнее

Не, ну это же фигня. API должно быть продуманным, а не тут отступление, там костыльчик. Потом понаделают клиентов, исправить эту кривость уже будет нельзя без переделки всех клиентов.

То же самое и про аватарку в author. Неважно какие сложности на сервере возникают у программистов, важно что имеем на выходе. А на выходе должно быть логичное API, где все методы в едином, понятном формате. Именно на таком качественном уровне софт должен общаться между собой, а не переносить внутренние недоработки куда-то наружу и продолжать в стороннем софте.

А список тредов так нельзя получить? Потыкал в воздух /tracker/threads, 404.