Здравствуйте, Merle, Вы писали:
M>Вот кстати по поводу запустить локально есть маленький req.: Вынести куда-нибудь в настройки, чтобы он не на rsdn.ru лез, а в то место куда ему укажешь...
Здравствуйте, WFrag, Вы писали:
WF>Насчет сортировки. Сортировать будет клиент дерева (перед установкой Nodes)?
Нет. Сортировать нужно не в памяти, а запросом. В будующем скорее всего придется делать более оптимальную загрузку. Ну, грузить первые 100-300 тем, а остальнеые или подкачивать в быкграунде, или по требованию (кодга пользователь начнет просматривать невидимые ему по началу темы). Так что сортировать нужно именно в запросе. Для этого нужно канкатинировать к запросу на выборку тем имена колонок по которым производить сортировку, ну, и DESC/ASC (порятод сортировки). Естественно, что передавать порядок нужно в виде некого энума. Да... передавать нужно в метод LoadData класса Msg.
Еще один вопрос в том как получать и отображать направление сортировки. В большинстве случаев получать можно путем обработки клика на колонке. Но вот, например, с датами так не прйдет. Дело в том, что самый удобный спостоб (используемый сейчас) — это сортировка по дате последнего обновления (она лежит в поле topic_info.answers_last_update_date) причем эта дата не отображается в гриде. Можно конечно заложиться на обработку поля дата, но при этом неясно как получить желание отсортировать по дате создания темы.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, m.a.g., Вы писали:
MAG>Кстати, насколько я понимаю, писать эту штуку с нуля будет жутким оверхэдом. Синхронизация Януса отрывается легко и перенастраивается на прокси, чувствую, что с сервисом будет та же штука. Проблема в том, что после этого получится по две реализации как веб-сервиса, так и клиента, которые поддерживать в синхронизованном состоянии будет достаточно трудно. Так что нужно рассмотреть вопрос выделения из Януса кода сериализации в отдельный проект и из сайта — вебсервиса. Тогда их можно будет достаточно просто сшить вместе и получить то, что надо.
MAG>Кстати, в чем на сервере хранятся данные? MSSQL?
Да. Причем формат БД отличается от формата локальной базы. Да и работать придется с данными отплевыемыми сервером. Так что общего кода там не будет. Ну, или будет очень мало.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, m.a.g., Вы писали:
VD>>Есть и более независимая задача. Нужно создать прокси-сервер. Этот сервер должен быть с одной стороны клиентом севриса на rsdn.ru, а с другой строны предоставлять такой же интерфейс (Веб-сервис). При этом сервер должен складывать запросы на обновление, кэшировать результат и отдавать, при запросх, данные из кэша. Данные лучше всего хранить в mssql (точнее в MSDE).
MAG>А вот это вполне можно сделать.
Давай. А то у нас до него руки еще долго не дойдут.
MAG>Только тогда давайте модуль в CVS и логин
Дадим. Только я тут не компетентен. Заведи новую ветку. Назови ее "Прокси". И в качестве одного из вопросов задай вопрос о логине. Завтра появятся зубры ЦВС-а и сделают тебе логин.
Вообще-то если ты будешь заниматься этим делом, но наверное будет лучше включить тебя в группу (ты ведь как я понимаю еще не вней?). Тогда тебе будет доступны исходники сервера и возможность прямого общения с девелоперами сайта.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>А мне сайт и нафиг не упал. (Хотя ИТ вроде рассказывал как это дело запускать.)
AVK>Так сервис без сайта не живет
Это что же там такого? Я тут со всех сторон слышу, что Хоум гад лезет в БД напрямую. Что же он цепляет если к БД он лезет сам?
PS
БД у меня работает.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Покажи. А вообще, чтобы меньше зависить от сервера нужно пользоваться параметрами. За исключением функций mssql понимает почти весь SQL от JET-а.
Здравствуйте, VladD2, Вы писали:
VD>Еще один вопрос в том как получать и отображать направление сортировки. В большинстве случаев получать можно путем обработки клика на колонке. Но вот, например, с датами так не прйдет. Дело в том, что самый удобный спостоб (используемый сейчас) — это сортировка по дате последнего обновления (она лежит в поле topic_info.answers_last_update_date) причем эта дата не отображается в гриде. Можно конечно заложиться на обработку поля дата, но при этом неясно как получить желание отсортировать по дате создания темы.
Я бы предпочел чтобы клик по колонке приводил к появлению выпадающего меню с пунктами нет, возраст., убыв.. У дат понятное дело пункты другие. ИМХО так даже удобнее чем стандартный клик по колонке.
Здравствуйте, VladD2, Вы писали:
VD>Это что же там такого? Я тут со всех сторон слышу, что Хоум гад лезет в БД напрямую.
Он лезет напрямую там где на момент написания не было промежуточного слоя. Списки форумов, права пользователя, добавление сообщений делается через библиотеки сайта.
Здравствуйте, AndrewVK, Вы писали:
AVK>Я бы предпочел чтобы клик по колонке приводил к появлению выпадающего меню с пунктами нет, возраст., убыв.. У дат понятное дело пункты другие. ИМХО так даже удобнее чем стандартный клик по колонке.
Лишние движения тоже вредны. Думаю меню есть смысл добавить только к дате (ну, и другим не однозначным пунктам).
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>Я бы предпочел чтобы клик по колонке приводил к появлению выпадающего меню с пунктами нет, возраст., убыв.. У дат понятное дело пункты другие. ИМХО так даже удобнее чем стандартный клик по колонке.
VD>Лишние движения тоже вредны.
Ты так часто меняешь порядок сортировки? Да и не сильно оно больше там движений — контекстное меню обычно показывают в непосредстьвенной близости от курсора. Зато то что из за случайного клика по заголовку, который находится рядом с другими кликоактивными элементами управления происходит изменение сортировки меня достает.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ты так часто меняешь порядок сортировки?
У тебя подход не конструктвный. Часто тут не причем. Например, я пароль и путь к БД задают только когда конфиг слетает. Но почему-то ты вынес его в настройку и не заставляешь лазить черти где, а потом перезагружать программу. Тут нужно подходить так. Лишние движения вредны априори. Их наличие нужно очень серьезно обосновать. Тогла приложение будет получаться удобным.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
MAG>>Кстати, в чем на сервере хранятся данные? MSSQL?
VD>Да. Причем формат БД отличается от формата локальной базы. Да и работать придется с данными отплевыемыми сервером. Так что общего кода там не будет. Ну, или будет очень мало.
Ничего не понимаю. Берется с сервера веб-сервис. Вставляется синхронизация с главным сервисом периодически/по входящему соединению. Код синхронизации берется из януса, чуток поколбасить SQL-запросов — не беда Получается прокси.
Здравствуйте, VladD2, Вы писали:
VD>Дадим. Только я тут не компетентен. Заведи новую ветку. Назови ее "Прокси". И в качестве одного из вопросов задай вопрос о логине. Завтра появятся зубры ЦВС-а и сделают тебе логин.
VD>Вообще-то если ты будешь заниматься этим делом, но наверное будет лучше включить тебя в группу (ты ведь как я понимаю еще не вней?). Тогда тебе будет доступны исходники сервера и возможность прямого общения с девелоперами сайта.
Да, это будет самое то (см. мое предыдущее сообщение).
Здравствуйте, m.a.g., Вы писали:
MAG>Ничего не понимаю. Берется с сервера веб-сервис. Вставляется синхронизация с главным сервисом периодически/по входящему соединению. Код синхронизации берется из януса, чуток поколбасить SQL-запросов — не беда Получается прокси.
Так тут вроде говорили, что вебсервис пол-сервера за собой потянет.
Здравствуйте, WFrag, Вы писали:
MAG>>Ничего не понимаю. Берется с сервера веб-сервис. Вставляется синхронизация с главным сервисом периодически/по входящему соединению. Код синхронизации берется из януса, чуток поколбасить SQL-запросов — не беда Получается прокси.
WF>Так тут вроде говорили, что вебсервис пол-сервера за собой потянет.
Здравствуйте, m.a.g., Вы писали:
MAG>Ничего не понимаю. Берется с сервера веб-сервис. Вставляется синхронизация с главным сервисом периодически/по входящему соединению. Код синхронизации берется из януса, чуток поколбасить SQL-запросов — не беда Получается прокси.
Прокси нужен не для того чтобы он был, а для того чтобы кешировать трафик. Вот это то и нужно реализовать.
.
Берется с сервера веб-сервис. Вставляется синхронизация с главным сервисом периодически/по входящему соединению. Код синхронизации берется из януса, чуток поколбасить SQL-запросов — не беда 
Получается прокси.