Автор Тема: SANITARIUM 2 ToDo List  (Прочитано 128400 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн Green Kakadu

  • Координатор
  • Глобальный модератор
  • Ветеран
  • *****
  • Сообщений: 2757
  • +1/-0
  • 0
    • Просмотр профиля
    • http://gnezdo.webscript.ru
SANITARIUM 2 ToDo List
« Ответ #60 : 02 Февраля 2005, 10:27:16 »
не а :) к сожалению оно пока не в том состоянии, чтоб всем показывать.. увы, оффлайновая работа отнимает слишком много времени, но я полон оптимизма, и надеюсь смогу скоро всех удивить (было б выходных побольше!)
 в исканиях.

Infringer2

  • Гость
SANITARIUM 2 ToDo List
« Ответ #61 : 02 Февраля 2005, 13:58:04 »
Много что писали чтобы хотелось видеть, но мне больше всего бы хотелось след.
1. чтоб база была SQL
2. рассылка подписчикам - желательно автоматическая
3. календарь
4. разграничение прав доступа и добавления статей и т.д.

Оффлайн Green Kakadu

  • Координатор
  • Глобальный модератор
  • Ветеран
  • *****
  • Сообщений: 2757
  • +1/-0
  • 0
    • Просмотр профиля
    • http://gnezdo.webscript.ru
SANITARIUM 2 ToDo List
« Ответ #62 : 02 Февраля 2005, 14:02:35 »
Цитировать
Infringer2:
1. чтоб база была SQL

хех, готовьте MySQL, то что будет SQL база это 100% пока на MySQL ориентируюсь

Цитировать
Infringer2:
3. календарь

да, календаааарь.. Вот не могу сообразить как бы получше его сотворить на статичных страницах. Вернее как сотворить -понятно (подцеплять javascriptом или инклудить), но получается будет лишь календарь на текущий месяц.
 в исканиях.

Оффлайн Cyberinfo

  • Завсегдатай
  • Новичок
  • *
  • Сообщений: 38
  • +0/-0
  • 0
    • Просмотр профиля
    • http://www.cyberinfo.ru
SANITARIUM 2 ToDo List
« Ответ #63 : 03 Февраля 2005, 12:55:47 »
а как тут можно уже готовый вариант довольно не плохо получилость и получается не 1 один мес. http://www.citynews.net.ua/

Оффлайн CTN

  • Заглянувший
  • Новичок
  • *
  • Сообщений: 26
  • +0/-0
  • 0
    • Просмотр профиля
    • http://www.citynews.net.ua/
SANITARIUM 2 ToDo List
« Ответ #64 : 03 Февраля 2005, 13:43:25 »
Green Kakadu
Цитировать
Infringer2:
хех, готовьте MySQL, то что будет SQL база это 100% пока на MySQL ориентируюсь

Хорошо бы, как в MovableType - выбор типа базы данных в настройках, а подпрограммы для работы с конкретными базами вынесены в отдельные модули (для начала можно оставить старую DB_File и добавить текстовую базу и MySQL, потом же при таком подходе все желающие после смогут добавить "драйвера" для работы с другими типами баз).

Цитировать
Вернее как сотворить -понятно (подцеплять javascriptом или инклудить), но получается будет лишь календарь на текущий месяц.


я отправлял ссылку на архив со своей нынешней верисией календаря... Может примерно так и организовать?



По поводу пожеланий к новой версии: очень было бы замечательно, если бы статьи сортировались не по id, а по дате (а также возможность изменения даты вручную при дополнении/обновлении материала).


Снова спасибо за скрипт! :)

Оффлайн Green Kakadu

  • Координатор
  • Глобальный модератор
  • Ветеран
  • *****
  • Сообщений: 2757
  • +1/-0
  • 0
    • Просмотр профиля
    • http://gnezdo.webscript.ru
SANITARIUM 2 ToDo List
« Ответ #65 : 03 Февраля 2005, 14:38:22 »
Цитировать
CTN:
я отправлял ссылку на архив со своей нынешней верисией календаря... Может примерно так и организовать?

;) я для этого и хотел взглянуть (и скачал), так что вполне возможно

Цитировать
CTN:
По поводу пожеланий к новой версии: очень было бы замечательно, если бы статьи сортировались не по id, а по дате (а также возможность изменения даты вручную при дополнении/обновлении материала).

угу, думаю для каждой категории можно будет задать поле по которому будет происходить сортировка. По дате/по последнему изменению/по алфавиту.
Дата теперь изменяется.


Цитировать
CTN:
Хорошо бы, как в MovableType - выбор типа базы данных в настройках, а подпрограммы для работы с конкретными базами вынесены в отдельные модули

это навряд ли. Допустим между SQL базами это сделать несложно, а вот чтоб BerkleyDB туда припахать ИМХО слишком много телодвижений надо сделать. И появится излишняя запутанность кода - одна из проблем теперешнего Санитара..
 в исканиях.

Оффлайн CTN

  • Заглянувший
  • Новичок
  • *
  • Сообщений: 26
  • +0/-0
  • 0
    • Просмотр профиля
    • http://www.citynews.net.ua/
SANITARIUM 2 ToDo List
« Ответ #66 : 03 Февраля 2005, 14:51:42 »
Green Kakadu
Цитировать
CTN:
это навряд ли. Допустим между SQL базами это сделать несложно, а вот чтоб BerkleyDB туда припахать ИМХО слишком много телодвижений надо сделать. И появится излишняя запутанность кода - одна из проблем теперешнего Санитара..

К сожалению, под рукой МоваблТайпа сейчас нет, чтобы точно описать, но, по-моему, там используется принцип чёрного ящика: есть подключаемые модули, один из которых подключается к скрипту в настройках, в модулях названия подпрограмм для получения/выдачи данных одинаковые. Модулю отдаются данные (или происходит обращение к подпрограммам модуля для получения данных) и скрипт потом не заботит, что происходит с данными после передачи или каким образом они взяты из базы.

Т.е. стандартизирована работа с базой, а под этот внутренний стандарт уже пишутся модули для разных баз.

Кстати, при таком подходе будет опять же несложно устроить перенесение данных из той же BerkleyDB в MySQL или что-то еще...

Оффлайн Green Kakadu

  • Координатор
  • Глобальный модератор
  • Ветеран
  • *****
  • Сообщений: 2757
  • +1/-0
  • 0
    • Просмотр профиля
    • http://gnezdo.webscript.ru
SANITARIUM 2 ToDo List
« Ответ #67 : 03 Февраля 2005, 15:30:24 »
Цитировать
CTN:
К сожалению, под рукой МоваблТайпа сейчас нет, чтобы точно описать, но, по-моему, там используется принцип чёрного ящика: есть подключаемые модули, один из которых подключается к скрипту в настройках, в модулях названия подпрограмм для получения/выдачи данных одинаковые.

да, я смотрел и в курсе реализации подобного.. но тут есть несколько моментов:
- приходится использовать дополнительный слой абстракции. Я буквально недавно переписал то что было на модифицированный SQL::Abstraction и потому в принципе легко использовать разные SQL БД, но если добавить BerkeleyDB то система утяжелится и усложнится, добавится некотарая избыточность. Тот же MT ИМХО весьма избыточен и не оптимален
- потребуется основательно перекромсать то что у меня есть сейчас и это мне больше всего не нравится :)
- Berkeley возникнут проблемы с сортировкой, она замечательно и оч.быстро работает с ключами, но если потребуется сортировка по какому-либо полю данных, то.. все считываем, разбиваем поля, берем нужное и сортируем непосредственно самим Perlом. Для больших контент- сайтов такие извраты будут весьма напряжными в смысле производительности
Цитировать
CTN:
будет опять же несложно устроить перенесение данных из той же BerkleyDB в MySQL или что-то еще...

это да.
 в исканиях.

Оффлайн Cyberinfo

  • Завсегдатай
  • Новичок
  • *
  • Сообщений: 38
  • +0/-0
  • 0
    • Просмотр профиля
    • http://www.cyberinfo.ru
SANITARIUM 2 ToDo List
« Ответ #68 : 04 Февраля 2005, 17:33:51 »
меня интересует еще такой вопрос как буду реагировать поисковые системы? т.е. сейчас ссылки одни потом я так понимаю вид c SQL версией станет совсем другой и получится будут ошибки 404. предложение такое сделать скрипт который при обработке 404 ошибки выдавал новый путь к статье!

Оффлайн Green Kakadu

  • Координатор
  • Глобальный модератор
  • Ветеран
  • *****
  • Сообщений: 2757
  • +1/-0
  • 0
    • Просмотр профиля
    • http://gnezdo.webscript.ru
SANITARIUM 2 ToDo List
« Ответ #69 : 04 Февраля 2005, 21:13:53 »
Цитировать
Cyberinfo:
предложение такое сделать скрипт который при обработке 404 ошибки выдавал новый путь к статье!


кстати дельное замечание, учту
 в исканиях.

Оффлайн CTN

  • Заглянувший
  • Новичок
  • *
  • Сообщений: 26
  • +0/-0
  • 0
    • Просмотр профиля
    • http://www.citynews.net.ua/
SANITARIUM 2 ToDo List
« Ответ #70 : 04 Февраля 2005, 22:06:58 »
Цитировать
Green Kakadu:
кстати дельное замечание, учту

По-моему, поисковики если получают в ответе сервера 404, то не индексируют то содержимое, что передаётся в виде страницы ошибки, а наоборот исключают адрес из индекса.

Разумнее вместо старых страниц разместить HTML-страницы с редиректом на новое расположение материала. Или же использовать mod_rewrite...



Так старая структура вообще сохранена не будет?

Цитировать
- Berkeley возникнут проблемы с сортировкой, она замечательно и оч.быстро работает с ключами, но если потребуется сортировка по какому-либо полю данных, то.. все считываем, разбиваем поля, берем нужное и сортируем непосредственно самим Perlом. Для больших контент- сайтов такие извраты будут весьма напряжными в смысле производительности

Это да, но мало ли — может кому-то надо будет временно на хостинге без MySQL пожить :-). Если страницы используются статические, то сервер одноразовый напряг при их генерации стерпит...

Цитировать
- потребуется основательно перекромсать то что у меня есть сейчас и это мне больше всего не нравится

понятно...

Оффлайн Green Kakadu

  • Координатор
  • Глобальный модератор
  • Ветеран
  • *****
  • Сообщений: 2757
  • +1/-0
  • 0
    • Просмотр профиля
    • http://gnezdo.webscript.ru
SANITARIUM 2 ToDo List
« Ответ #71 : 04 Февраля 2005, 22:36:59 »
Цитировать
CTN:
Разумнее вместо старых страниц разместить HTML-страницы с редиректом на новое расположение материала. Или же использовать mod_rewrite...

я это и имел в виду. т.е. создать скриптик который бы выискивал соответствия (старый урл/новый) и переправлял
Цитировать
CTN:
Так старая структура вообще сохранена не будет?

нет.
/название_категории/id_статьи/название статьи
по идее разница лишь в том, что у категорий будут не номера, а названии (+не стоит забывать про подкатегории), ну а название статьи  - это по желанию
 в исканиях.

Оффлайн Green Kakadu

  • Координатор
  • Глобальный модератор
  • Ветеран
  • *****
  • Сообщений: 2757
  • +1/-0
  • 0
    • Просмотр профиля
    • http://gnezdo.webscript.ru
SANITARIUM 2 ToDo List
« Ответ #72 : 04 Февраля 2005, 22:47:25 »
Цитировать
CTN:
 то сервер одноразовый напряг при их генерации стерпит...

хех, тут тебе виднее. Я то санитаром вообще не пользовался (запостил пару статеек и забросил это дело). Т.е. с трудом представляю как там обстоит работа при большом кол-ве статей. Мне кажется неудобно :)

наверное самый "объемный" сайт с санитаром, это http://www.gtnews.ru/  они работают в динамич.режиме, и возможно в этом есть логика, потому как генерить статику будет неудобно. (Правда при динамич.режиме довольно прилично ресурсов тратится на при построении индексных страниц)

Поразмыслив, мы с NASом решили при генерации сделать что-то типа "Генерить изменившиеся страницы за такой-то период" (день, три дня, неделя, месяц, квартал, год)
 в исканиях.

Оффлайн CTN

  • Заглянувший
  • Новичок
  • *
  • Сообщений: 26
  • +0/-0
  • 0
    • Просмотр профиля
    • http://www.citynews.net.ua/
SANITARIUM 2 ToDo List
« Ответ #73 : 04 Февраля 2005, 23:26:49 »
Цитировать
Green Kakadu:
/название_категории/id_статьи/название статьи по идее разница лишь в том, что у категорий будут не номера, а названии (+не стоит забывать про подкатегории), ну а название статьи - это по желанию

Это через mod_rewrite или же
/script.cgi/название_категории/id_статьи/название
?

Неплохо, кстати, в динамике выдавать в заголовках страницы Last-Modified и т.п. для поисковиков — чтоб считали выдаваемую страницу статической :)

Цитировать
Green Kakadu:
хех, тут тебе виднее. Я то санитаром вообще не пользовался (запостил пару статеек и забросил это дело). Т.е. с трудом представляю как там обстоит работа при большом кол-ве статей. Мне кажется неудобно

Ну не знаю, насколько виднее :)
Особых неудобств не заметил... Да и потенциально нагрузка на сервер меньше — одно дело при запросе генерить страницу, получая данные из базы, обрабатывать данные и навешивать их на шаблон перед выдачей, и другое — просто выдавать готовую страницу, возможно, с минимумом динамики (серверный счётчик, пара ssi-include\'ов и т.п.).

Цитировать
Green Kakadu:
 они работают в динамич.режиме, и возможно в этом есть логика, потому как генерить статику будет неудобно.

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

С другой стороны, поисковики очень любят статические страницы.

Цитировать
Green Kakadu:
 (Правда при динамич.режиме довольно прилично ресурсов тратится на при построении индексных страниц)

И я о том же... С SQL, конечно, на порядок меньше будет ресурсов расходоваться, но всё равно — любая динамика по ресурсам проигрывает статике :)


Цитировать
Green Kakadu:
Поразмыслив, мы с NASом решили при генерации сделать что-то типа "Генерить изменившиеся страницы за такой-то период" (день, три дня, неделя, месяц, квартал, год)

А так, как сейчас чем не подходит? (генерация страниц только при публикации/редактировании статей)

Оффлайн Green Kakadu

  • Координатор
  • Глобальный модератор
  • Ветеран
  • *****
  • Сообщений: 2757
  • +1/-0
  • 0
    • Просмотр профиля
    • http://gnezdo.webscript.ru
SANITARIUM 2 ToDo List
« Ответ #74 : 04 Февраля 2005, 23:47:55 »
Цитировать
CTN:
А так, как сейчас чем не подходит?

не это подходит, но допустим если закинули сразу несколько статей, то чтоб каждый раз не генерить (индексы же все равно общие), сразу оптом.
 в исканиях.

 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28