Гм... Аватары для записей выбираться будут? Еще было бы хорошо, если бы синхронизировались состояния и категории, т.е. те что есть он-лайн были бы и офф-лайн.
Arkane со всем тем функционалом, который есть в вебе, но нету в оффлайне, есть некая проблема. Дело в том, что оффлайновый клиент использует другой интерфейс доступа, чем обычная веб страница.
Такие вещи, как выбор аватара, закачка аттачей, простановка категори и т.п есть в вебе, но нету в том скрипте, который использует клиент для отправки записей. По идее нет проблем отправлять из клиента через интерфейс веб-страницы - но у нее нет одной важной для оффлайнового клиента фичи: отправки задним числом.
cpcat с тем же успехом могут изменить и интерфейсы клиента. А что делать
У меня там все довольно просто написано - так что при смене имен полей запроса апдейтнуть софтину проблем не составит.
Интерфейс клиента изменить сложнее - им сотни людей пользуются.
Возможно есть смысл сделать для желающих расширенного функционала "прокси" на своём хостинге, который будет использовать оба интерфейса и всегда поддерживаться в текущем состоянии, там же было бы неплохо (губы раскатал) sms-гейт и mail-гейт с возможностью ответа на комменты сразу по почте.
А для остальных - только то, что даёт клиентский интерфейс.
Короче.
Выглядит это так.
У клиента есть три режима: "Базовый", "Расширенный" и "Смешаный".
Базовый - это режим, когда для отправки записей используется интерфейсы обычногого десктопного оффланового клиента. В нем не доступны "специальные" фичи, такие как аттачи файлов, выбор автара, группы записи и т.п. Зато этот режим независим от интерфейсов скрипта newpost.php, т.е. должен работать даже в случае, если форму отправки сообщения всерьез изменят. Так же в нем поддерживается отправка записи задним числом - т.е. числом написания поста.
Расширенный режим отправляет записи в стандартный скрипт приема веб-формы поста - тот, которым мы пишем посты через браузер - newpost.php. Поэтому он поддерживает все его фичи, однако не поддерживает режим отправки задним числом и теоретически может перестать быть работоспособным в случае изменения именования элементов управления на форме отправки новой записи.
Есть еще смешанный режим. В этом режиме сначала происходит размещение записи аналогичное Базовому - т.е. через специальный интерфейс клиента. Это позволит, например, отправить запись задним числом. После чего, для загрузки информации для всех специальных фич (аватары, аттачи, группы, ...) автоматически выполняется редактирование записи - т.е. данные отсылаются скрипту editpost.php.
В смешанном режиме получается создать "богатую" запись задним числом. Однако есть существенный недостаток: для того, чтобы отредактировать созданную запись, надо знать ее id, который на момент создания не известен. Поэтому осуществляется еще один дополнительный GET запрос к серверу (запрос к скрипту journals_comments.php с параметром action=lastpost), который, в частности, позволяет узнать id последнего поста. Это дополнительный запрос ест дополнительный траффик и требует времени на выполнение.
Выбор режимов будет доступен пользователю в настройках программы.
ой, как все это здорово!
нужно прибавить, что в нынешнем оффлайн-клиенте некорректно работает [URL] (добавляется хреф) и нет [CUT]. спасибо вам большое заранее)
Алекс Лочер, а ваше изобретение может потом использоваться при некотором улучшении как обычный оффлайн-клиент? а то надоели его затупления, а у администрации нет времени на обновления(
еще раз повторюсь - вы молодец!
jaba можно. Клиентская библиотека пишется на .Net Compact Framework - а она, будучи сужением обычной полноценной .Net Framework, полностью переносима снизу вверх на обычный ПК. Только интерфейсную программу переписать - это потом либо я сделаю, либо кто другой, знакомый с этой технологией - это не сложно.
проблема в другом - интерфейсы достура к journals все равно ограничивают функциональные возмождности клиента теми, что предусмотрены создателями сайта. И если отправку сообщений еще можно обойти через "расширенный режим" (см выше), то все остальное - нет.
Алекс Лочер, это я все уже внимательно прочитала. и все-таки, я полагаю, лучше иметь функциональный клиент, неспособный делать записи задним числом, чем устаревший, но способный. на крайняк можно тот хранить для автономного режима...
хотя и я работаю бок о бок с программистами, они все-таки непостижимые люди, способные сделать какие-то невероятные вещи) я, например, даже радио не смогла бы собрать)
Zabudka да не люблю я слаботипизированные необъектные скриптовые языки прогрммирования. Плохо мне от них - тоска одолевает Без крайней необходимости стараюсь не писать на них