6 января 2005 в 4:26
Задача.
Создать сайт, объединяющий несколько фотокружков. Фотографируем много и часто. Графики предполагает быть много. По этой причине большое внимание уделяется галлерее.
Сейчас стою перед выбором - подбирать портальную систему со встроенными модулями: новости, статьи, форум, блог(и), галлерея. Или собрать сайт из модулей не завязанных одной "крышей. Например "крыша"+сторонняя галлерея (форум, блог). В этом случае стоит проблема общей авторизации. Как ее решать если пойду по этому пути - не знаю.
По галлерее.
Фото сортируются по многим разделам (пейзажи, портреты, животные, события....) плюс желательны персональные галлереи. Каждое фото имеет обязательные описательные атрибуты:
какой камерой сделан снимок,
Дата
Время
Место
Автор.
Желательно, чтобы эти атрибуты (поля для атрибутов) можно было самостоятельно добавлять (удалять).
сортировка и выборка по этим атрибутам
Краткое описание.
возможность откомментировать снимок.
возможность добавить родственные ссылки (фотографии этого автора, фото этого места других авторов, еще сиамские кошки.... ).
режим предпросмотра.
Возможность заливки изображений, зарегестрированными пользователями, Голосования (рейтинги) изображений, статистика популярности.
Требования к системе.
Бесплатность
Легкое измнение дизайна (желательно не в виде темплейтов, а именно возможность легко создать свой униккальный дизайн, но это не критично)
Поддержка коротких URLов (не знаю как правильно называется)
Хорошая индексируемость (дружба с поисковыми пауками)
Информационная поддержка на русском.
Что на ваш взгляд будет оптимальным (правильным) решением?
Уровень подготовки для самостоятельной работы с кодом ниже среднего.
Знаю HTML, CSS.
PHP на уровне понимания того что написано - не более. C MYSQL отношения - найти, вставить, залить готовую базу, создать пустую базу.
Вот. Старался быть кратким.
Комментарии
drupal врядли подойдет, надо делать отдельный движок, если хочешь чтоб было все действительно "хокей", но тут уже бесплатность отпадает...
Даже не буду спорить с заявлением предыдущего оратора.
Все вышеперечисленное можно реализовать в drupal, притом, если я правильно понял задачу, без дополнительного кодинга и твиканья.
Конкретно по пунктам - могу ответить или, если что-то не реализуется стандартыми средствами, предложить обходные решения.
если найдется способ как контент созданный через flexinode отображать по разным полям - сортировка, отбор - то можно его. а вообще решений через друпал слишком много -главная проблема выбрать.
ОК, тогда расскажи, как можно в drupal реализовать нижеследующее:
"Легкое измнение дизайна (желательно не в виде темплейтов, а именно возможность легко создать свой униккальный дизайн)"
Теперь по существу.
В любом случае лучше делать сайт на одном скрипте. Интегрировать друг в друга разные продукты - дело более геморное. Сколько бы открытыми они не были. В Друпал есть различные модули для работы с изображениями, в принципе должны подойти. Ничего крутого в их реализации нет и если новостная часть сайта не предполагается навернутой по фичам, то полагаю имеет смысл посмотреть на другие CMS, где галереи могут быть реализованы лучше (а новости в каком-нибудь простом виде в любом CMS можно публиковать). Модуль image имеет другой набор полей, но можно либо его дописать, либо использовать flexinode для построения документа со своим набором полей. Комментировать в Друпал можно любые документы (aka "ноды"). Персональные галереи в модуле image были насколько помню. Это также всё есть в разных модулях. Если под "легким изменением дизайна" ожидается, что это можно сделать подвигав блоки в административном интерфейсе сайта - то таким образом можно сделать немногое. Для действительно хорошего оригинального дизайна надо его делать ручками. Друпал позволяет много способов вставить вывод движка в страницы сайта, как используя различные механизмы шаблонов, так и напрямую кодом на php обращающимся к функциям друпал. Поддержка коротких URL в движке весьма продвинутая. Для удобств поиска потребуются определенные требования к хостингу (php собранный с расширением mbstring), хотя поиск будет работать и без них, но в более простом виде. Вероятно имеет смысл обратиться к специалисту для настройки/допрограммирования сайта, а самому делать дизайн на свой вкус.Это вам решать
--
Axel
"В любом случае лучше делать сайт на одном скрипте. Интегрировать друг в друга разные продукты - дело более геморное."
Согласен. Но на самом деле, можно не интегрировать.
Я смотрю на здешний форум (его ведь можно считать наглядным примером встроенного друпаловского форума?) и вижу, что он даже близко не приближается по удобству к специализированным табличным форумам (invision, vbulletin, phpbb). Исключительно с точки зрения эргономики.
В качестве форумного движка я сейчас пристально приглядываюсь к invision board (версия 2.0 и выше требует платной регистрации, версия 1.3 и ниже могут использоваться свободно). vbulletin, к сожалению, не разрешает бесплатного использования ни одной из своих версий.
Получаем четыре возможных варианта реализации:
1) сайт и форум на одном движке, общая авторизация, форум сомнительного удобства
2) сайт и форум на разных движках, общая авторизация, куча геморроя по сращиванию движков
3) сайт и форум на разных движках, независимая авторизация
4) сайт и форум на разных движках, для внешнего наблюдателя авторизация есть только на форуме (материалы на сайт вносятся узким кругом людей, которые знают адрес странички с авторизацией)
Первый вариант мне активно не нравится, как я уже сказал, форум тут с моей т.зрения имеет неважную эргономику. Может, конечно, вопрос дизайна: сейчас форум легко перепутать с материалами сайта. С моей т.зрения, это не есть достоинство, т.к. у форума и статейной части разная специфика.
Второй вариант предельно близок к идеалу, но на этот вариант мне, увы, ни времени ни сил не хватит.
Третий и четвертый вариант требуют размышления о степени большего удобства. Что лучше: разрешить возможность комментирования статей или волевым решением вынести все обсуждения на форумный движок, специально и всесторонне заточенный как раз под обсуждения? Лично я склоняюсь в пользу именно такого решения.
____________
Есть только одно но: у меня сложилось ощущение, что за вопросами поиска и ликвидации уязвимостей в отношении drupal следят не в пример пристальнее, чем в отношении форума ib v1.3, тем более что 1.3 - не последняя версия форума и значительная часть заплат выпускается только для более поздних версий, не распространяющихся бесплатно.
____________
То, что dupal имеет слабенький встроенный форум, меня не удивляет и кажется вполне закономерным. Первоосновой является сайт. Форум - лишь попытка адаптировать средства сайта для имитации форума. Но форум - это не просто "отправка-чтение-модерирование" сообщений. И это не просто "дерево сообщений". Это слишком примитивный подход, срабатывающий, когда у нас этих сообщений немного. Как только их количество вырастает на порядок-два, становится ясно, что либо надо их по другому структурировать, либо в этом хаосе просто очень сложно искать обновления/ответы. Специализированные форумные движки веками шлифовались для наилучшей реализации своей задачи. Поэтому если хочется делать не хуже чем они, надо для начала делать как они.
Вообщем выражаю свое imho.
А я вот считаю эти движки крайне неудобным...
А все из-за одного ... Они не умеют строить дерево комментов...
Начинаешь читать длииинный топик. Тред там плоский, поэтому чтобы было понятно, что на чей комментарий отвечают используют цитирование. На ... комментарии этак 20 понимаешь всю прелесть этого... Перед сообщением процитировано сообщений так 5... а то и больше ... И .. каждый раз приходится это перечитывать (чтобы понять что же комментирует очередной автор)... Даа... Сразу начинаешь чувствовать "веками отшлефованное" удобство...
Дело в том, что реализовать древовидный тред несколько сложнее... Поэтому, imho это использование плоского трэда сильно смахивает на элементарную лень разработчиков (эм.. а ведь за некоторые из них деньги берут!?!)...
Да.. Может быть какие-то элементы там удобнее... Но... все они сводятся на нет одним, но зато большим и жирным неудобством...
Если делать как кто-то, то всегда будешь в роли догоняющего... Не лучше ли думать свои мысли и реализовывать свои идеи?..
По поводу интеграции:
Еще раз прошу хорошо задуматься...
В пример приведу вам сайт mozilla.ru. Где форум отдельно, сайт отдельно. Реализован Ваш пункт 4. И что же мы видим?! Страничек на сайте по пальцам пересчитать. Зато на форуме!!
Вам не кажется это странным?.. Лично мне кажется ... Если бы не эта ссылка, то за последними руссификациями на форум я пошел бы в пследнюю очередь... Между тем на форуме даже ветки отдельно созданы для руссификаций... расширений .. и т.д. Вообщем, форум по сути стал сайтом...
И похоже, что ребятам из mozilla.ru пора уже
moziila.ru CNAME forum.mozilla.ru
И, уверяю Вас, это не единственный сайт с такой проблемой...
Так что ... Подумайте еще раз по поводу интеграции...
--
USU-Lug http://usu-lug.org.ru
ОК, по твоему необходимость цитировать то, на что отвечаешь - есть следствие табличной структуры (в противовес прогрессивной, древовидной), так?
Что-то не сходится.
Вот мы сейчас общаемся, используя древовидный форум. И почему-то это не избавляет от необходимости цитировать то, на что отвечаешь. Причем ты пользуешься этим цитированием активней чем кто-либо.
Нифига. На заре исторического материализма все форумы были древовидными. До табличных тогда просто не додумались.У древовидных usability хуже. Когда сообщений немного, ветвястая структура может быть и удобнее. А вот когда количество сообщений, появляющихся в интересующем тебя форуме и на интересующие тебя темы превышает, скажем, двести в сутки, следить за ними становится не в пример сложнее.
Форумы с высокой нагрузкой не зря все являются табличными.
Я не использую цитирование с целью обозначения на чай коммент отвечаю.
Вот если бы этот коммент был не здесь в в конце трэда, то мне пришлось бы процитировать. Или написать ваш ник в начале сообщения, что равносильно постраению дерева только в голове читающего (не лучше ли эту работу будет делать машина?).
А вот вы попробуйте разабраться в плоском треде с 200ми сообщениями
Чтобы ответить на последнее сообщение, вам с большой вероятностью придется прочитать весь тред.
А в древовидном, достаточно прочитать только ветку...
Вообщем, ситуация "о фкусах не спорят". Поэтому предлагаю больше не развивать это обсуждение?..
Каждый высказал свое мнение....
--
USU-Lug http://usu-lug.org.ru
Хех... Только тогда бы вы не поняли, что я отвечаю именно на ваш комментарий...
Это бы больше по ходило на размышления вслух...
Как минимум мне пришлось бы написать вот так
[b]PG[/b],
Что равносильно построению дерева, только в голове читателя.... (вообщем и так далее дубль 2...)
--
USU-Lug http://usu-lug.org.ru
То, что dupal имеет слабенький встроенный форум, меня не удивляет и кажется вполне закономерным. Первоосновой является сайт. Форум - лишь попытка адаптировать средства сайта для имитации форума. Но форум - это не просто "отправка-чтение-модерирование" сообщений. И это не просто "дерево сообщений". Это слишком примитивный подход, срабатывающий, когда у нас этих сообщений немного. Как только их количество вырастает на порядок-два, становится ясно, что либо надо их по другому структурировать, либо в этом хаосе просто очень сложно искать обновления/ответы. Специализированные форумные движки веками шлифовались для наилучшей реализации своей задачи. Поэтому если хочется делать не хуже чем они, надо для начала делать как они.[/quote]
Тут полностью согласен со всеми утверждениями, кроме последнего, что надо делать как уже сделано в известных форумных движках. Пойти их путём это значит повторить их главную ошибку, а именно - форумы есть отдельный вид контента, не пересекающийся (или малопересекающийся) с остальным сайтом. Это вырождает форумы в обычный чат. Блоги (в виде ЖЖ) в таком случае выглядят куда лучше, поскольку там категоризация хотя бы происходит не принудительно (по воле админа форума, создающего список форумов и бьющего его на категории по своему усмотрению), а естественным путём - тематические сообщества на основе "лент друзей" и "коллективных блогов".
Моя идея, которую пробую реализовать в альтернативном форуме для Друпал - у нас есть единый контент сайта, состоящий из документов разных типов (попросту содержащих разный набор полей - статьи, изображения, опросы и т.д.) и есть разные представления для него, пользователь сам выбирает наиболее для него удобное, как например:
- новостное - сплошная лента новостей из всех документов, которые можно комментировать, документы привязаны к категориям таксономии, по которым их можно фильтровать по тематикам
- форумное - фактически доп. способ фильтрации по категориям на основе списка форумов, плюс с сохранением фильтрации по другим тематикам, не отражённым в списке форумов
- блоговое - разбиение статей по авторам, по-прежнему с возможностью фильтрации по тематикам
На мой взгляд, на основе Друпал эта задача решается проще, чем дописание функциональности к форумным или блоговым движкам. Вопросы внешнего представления форумов и блогов, чтобы они выглядели "по форумному" или "по блоговому" - это уже детали реализации дизайна, к движку отношения почти не имеющие. Можно в конце концов разнести сайты, как я уже упомянул пример для drupal.ru и forum.drupal.ru (это правда эксперимент и я сам не знаю какие глюки могут вылезти :)).
Возвращаясь к форуму в Drupal - тут определенно нужен модуль массовой модерации, тогда форум будет вполне конкурентоспособен (остальные фичи добавляютс разными доп. модулями). Мне впрочем стандартный модуль не нравится ещё и внутренней организацией, скромно отмечу что мой альтернативный akvaforum (см. CVS sandbox/axel/akvaforum) генерит более оптимальные и простые запросы и по времени работает быстрей (хотя по функциям он сейчас близок к стандартному модулю - такой же никакой :)). Главное отличие, он позволяет публиковать топики из любых типов нодов, т.е. публиковать опросы или изображения в форуме и т.п. Ведь мы можем подключать модули для самых разных видов контента и публиковать их в форумах, получая т.образом отдельные форумы со специального вида топиками. Например в форуме Галерея - постим картинки, в форуме Обзоры - обзоры статей с возможностью голосовать за них, в остальных форумах - что-то ещё. Учитывая лёгкость подключения новых модулей в Drupal можно получать весьма сложные структуры. Я не видел такой фичи в форумных движках.
--
Axel,
www.axel.drupal.ru
"Я вот для одного из сайтах планирую в будущем (когда доделаю альтернативный модуль форумов) перевести его с Invision на Drupal."
Ключевой момент - "когда доделаю альтернативный модуль форумов".
Светлое будущее нам несет много интересного: например модуль интеграции друпал с vb или ib, или например встроенный форум, способный конкурировать с самыми известными и развесистыми форумами-монстрами.
Но мне казалось, что мы обсуждаем не то, что будет в светлом будущем, а то, что доступно "здесь и сейчас".
Форумные движки стремятся обзавестись порталами, чтобы в случае, если сайт реализуется на базе исключительно форумного движка, и кроме форума больше ничего нет, можно было бы соблюсти хотя бы видимость приличия. Хотя бы видимость наличия сайта. В виде ленты новостей. При этом выбирается один из подфорумов и представляется в "блоговой" форме, когда первое сообщение каждого треда - это запись в блоге, а остальное - комментарии к нему.
Прочая информация на странице блога (типа "последних обновившихся тредов" или "последних зарегистрированных пользователей") - это уже откровенные рюшечки, которые могут разве что привлекать внимание случайных посетителей.
При этом замечу, что никто не пытается перемешивать, собственно, форум и ленту новостей. Да, один из подфорумов превращен в новостной коллективный блог, но остальные форумы как были форумами, так ими и остались.
Это что касается порталов.
Но есть вещь, которой у порталов нет вовсе. Это статейная часть. Иерархия документов со статьями на какие-то темы. Статьи пишутся авторами. Статьи можно обсуждать. Но они ни коим боком не являются форумным общением. Совершенно другое представление информации. Совершенно другая концепция. Общение - само по себе. Статьи - сами по себе. Статьи можно обсуждать. Но совершенно незачем это делать прямо внутри статьи! Это будет вносить только путаницу. Мысль понятна?
О! Форумы, по сути своей, и есть "обычный чат". То бишь общение нескольких людей. Не создание справочника. А именно общение.Хотя будем говорить честно - "чат" этот не совсем обычный, ибо любой вступающий в продолжающуюся дискуссию может быть заранее подготовлен, поскольку у него есть возможность проследить течение дискуссии назад на произвольную глубину. Произвольность глубины, кстати, выгодно отличает форумы даже от эхоконференций, хотя в остальном они очень и очень схожи.
Идея любопытная (хотя не уверен что правильная), кроме одного замечания: это всё распространяется на сообщения форума. Но никак не на все документы сайта. Форум - это еще не сайт, у сайта есть и другие грани. Не надо сводить весь сайт к одному большому форуму с сильно вырожденной формой представления. ОК, поясни мне разницу между "коллективным блогом" на заданную тему и форумом на заданную тему. Абстрагируясь от способа их создания. (Если кому-то приспичит, он легко заведет что форум что блог на любимую тему.)Он древовидный. Причем сам юзер выбирает как смотреть треды линейно или древовидно
Они в качестве эксперимента попробовали угодть "и нашим и вашим" и сделали его представление кастомизуемым. (Полностью перелопатив структуру базы сообщений.)
При этом, если кто-то, у кого представление линейное начинает отвечать как обычно - в одном сообщении сразу на все сообщения треда, требующие ответа, то поймут его потом только те, кто тоже смотрит форум линейно.
В результате, в таких гибридных форумах, если кто-то продолжает ими пользоваться традиционно, все кто пытается работать древовидно, оказываются в проигрыше.
Но это ведь отключаемо в настройках. Это на drupal.ru такие эксперименты, а вообще я вот на других сайтах предпочитаю выставить один способ - дерево или список, без разрешения пользователям его менять. Но мне лично симпатчней древовидные сообщения.
--
Axel,
www.axel.drupal.ru
У дерева есть масса недостатков, и главный из них - как выделить в общей куче новые сообщения.
Представь себе, что у нас дерево имеет 80 ветвей от одного корня. А на страницу их выводится 50. Как ты отметишь новые? Сделаешь их сверху? Ага, давайте свежие делать сверху. И ветки со свежими сообщениями делать сверху. Но тогда если ты не читал этот "куст" вообще весь, тебе придется его изучать с конца к началу, потому что более ранние сообщения будут в конце. Это удобно? Не уверен.
Второе. Окей, у нас при каждом заходе отмечаются сообщения, добавившиеся с нашего прошлого посещения. Однако что-то нас отвлекло (или их просто много слишком обновилось) и мы успели прочитать не все помеченные сообщения.
И привет: для того, чтобы их разыскать, придется тупо перебирать все сообщения (а каждое сообщение - это отдельная HTML страничка, т.е. здравствуй траффик!), дабы чисто визуально найти среди них незнакомые.
Я еще НИГДЕ НИКОГДА не встречал бы реализацию древовидного форума, которая была бы лишена двух перечисленных недостатков:
а) как совместить удобство первого ознакомления с удобством вынесения обновившихся сообщений на первую станицу форума.
б) как искать "новые сообщения" вашего прошлого/позапрошлого посещения, до прочтения которых у вас не дошли руки.
Если я увижу реализацию, лишенную указанных, крайне мерзких недостатков, я, возможно, пересмотрю свое презрительное отношение к древовидным форумам.
Спою еще пару дифирамбов табличным форумам.
Во первых, как мы уже выяснили, тамошняя необходимость цитировать сообщение на которое отвечаешь, не слишком-то отличется от древесной: при ответе на последнее сообщение его нормальные люди не цитируют, ибо его и так видно.
А при ответе на более ранние сообщения треда, цитируется, как правило, не всё сообщение, а конкретный абзац, после которого пишется ответ на этот конкретный абзац. Такая "фидошная" схема цитирования и дереву не помешала бы.
Да, вместо разнесения отдельных сообщений на отдельыне страницы, все сообщения вываливаются разом. Но при традиционной дискуссии, приходится так или иначе следить за всеми ответами, даже за непрофильными, ибо в последующих сообщениях косвенно может упоминаться или подразумеваться информация, которая там упоминалась. Если ты ее не прочел - ты выпал из контекста.
И тут уже плюсы дерева оборачиваются минусами, ибо каждый текст в собственной обертке - это в сумме гораздо более увесистый траффик, нежели все тексты одной доской.
Я согласен насчёт того, что табличные форумы более удобны для большого количества сообщений. Но это удобство есть не следствие недостатков древовидной формы, а следствие примитивности средств в вебе для работы с деревьями. Да, можно делать их на JavaScript - что будет предоставлять разные удобства, но учитывая своеобразие реализаций JS можно огрести немало проблем. К тому же JS обрабатывается броузером, т.е. трафик это не уменьшит никак - целые ветки будут забираться и только локально их можно будет раскрывать/закрывать и т.д.
Вот если отвлечься от веба и посмотреть скажем на почтовые клиенты - в них очень приятно работать именно с нитками сообщений. Каких-то неудобств это не вызывает, напротив. Ассоциация конечно не особо корректна - в почте только с сабжектами обычно идёт работа в списке писем. Это вот если комменты отображать иключительно по сабжам и разворачивать/сворачивать отдельные ветки - может быть удобно. К сожалению, сложившийся в форумах стиль общения не подразумевает наличия внятных сабжей (да и в почте на это порой люди забивают).
--
Axel,
www.axel.drupal.ru
Форум на java в большинстве случаев есть
а) потеря универсальности
б) потеря возможности дать другому ссылку на конкретное сообщение.
Исключений мне еще не попадалось.
"Вот если отвлечься от веба и посмотреть скажем на почтовые клиенты - в них очень приятно работать именно с нитками сообщений."
Мне кажется, проблема в том, что надо придумывать какой-то механизм, завязанный не на сабжи, а на что-то иное. На какой-то ключ, обозначающий, что вот это письмо является ответом на это, а то в свою очередь на то.
Какой-то 64-битный ключ, который случайным образом генерится автоматически для первого письма и который ты можешь удалить, если посылаемый тобой ответ не является ответом непосредственно на обсуждаемую вами тему.
Но это мы уже ушли в гнусный оффтопик.
Пока замечу, что нынешняя друпаловская реализация по эргономичности не доходит даже до примитивных табличных. Что уж тут говорить о древовидной форме! (Кстати, не о древовидной, а тогда уж о сетевой: если одно сообщение может быть ответом на несколько разных, так почему бы это не формализовать?)
И я предлагаю ориентироваться именно на табличники, либо надо начинать мутить очень серьезный проект, который для доведения до пригодности к показу потребует очень-очень много программинга.
Такой ключ есть.
Каждое email сообщение имеет уникальный message-id.
А.. когда ты нажимаешь кнопочку "Ответить" клиент добавляет в заголовок письма строку
In-Reply-To: message_id
Именно ориентируясь на это, клиент, который примет сообщение, может построить трэд.
--
USU-Lug http://usu-lug.org.ru
А в продвинутых почтовых клиентах вроде mutt эти заголовки можно выносить на редактирование при ответе на письмо - просто в тексте ответа их видно и можно править.
--
Axel,
www.axel.drupal.ru
Хотя попробовал сейчас включить в настройках комментариев "древовидный - свёрнутый", а не так уж и неудобно
Вот действительно, сабжекты бы люди не ленились писать - вовсе было бы чудесно 
--
Axel,
www.axel.drupal.ru
И ещё удобно бы в свёрнутом дереве отображать помимо заголовков продолжения сообщения (первые несколько строк по наведению мышки). /me задумался о правке comment.module.
--
Axel,
www.axel.drupal.ru
Патч к comment.module для 4.5 добавляющий в свёрнутом изображении комментариев дату комменатария и в title ссылки текст начинающий комментарий (сотня символов). Вообще в comment.module это всё очень грамотно вынесено в themable функции, т.е. можно без правки модуля всё переписать в теме и выводить комментарии как захочется. Но пока с темой возиться неохота, вот после обновления дизайна перенесу изменения в функцию темы.
А пока патч к модулю:
<?php
--- modules/comment.module 2005-01-12 19:01:55.000000000 +0300
+++ /home/axel/public_html/drupal.ru/modules/comment.module 2005-02-19 23:31:55.000000000 +0300
@@ -534,15 +534,17 @@
$edit['subject'] = truncate_utf8(strip_tags($edit['comment']), 29);
}
- if (!form_get_errors()) {
// Check for duplicate comments. Note that we have to use the
// validated/filtered data to perform such check.
$duplicate = db_result(db_query("SELECT COUNT(cid) FROM {comments} WHERE pid = %d AND nid = %d AND subject = '%s' AND comment = '%s'", $edit["pid"], $edit["nid"], $edit['subject'], $edit['comment']), 0);
if ($duplicate != 0) {
watchdog('warning', t('Comment: duplicate %subject.', array('%subject' => ''. $edit["subject"] .'')));
+ drupal_set_message(t('Duplicate comment. You comment already posted! Don\'t clone it!'), 'error');
}
+ if (!form_get_errors() && !$duplicate) {
+
if ($edit["cid"]) {
// Update the comment in the database. Note that the update
// query will fail if the comment isn't owned by the current
@@ -1459,6 +1461,7 @@
// Emit selectors:
$output = '';
+
if (node_is_new($comment->nid, $comment->timestamp)) {
$comment->new = 1;
$output .= "\n";
@@ -1591,8 +1594,9 @@
function theme_comment_folded($comment) {
$output = "
- $output .= ' '. l($comment->subject, comment_node_url() .'/'. $comment->cid, NULL, NULL, "comment-$comment->cid") . ($comment->new ? ' '. theme('mark') : '') .' ';
+ $output .= ' '. l($comment->subject, comment_node_url() .'/'. $comment->cid, array("title" => truncate_utf8($comment->comment, 128)), NULL, "comment-$comment->cid") . ($comment->new ? ' '. theme('mark') : '') .' ';
$output .= ''. t('by') .' '. format_name($comment) ."\n";
+ $output .= "". strftime("%d/%m/%Y - %H:%M", $comment->timestamp). "";
$output .= "
\n";
return $output;
}
@@ -1609,6 +1613,7 @@
}
function theme_comment_thread_min($comment, $threshold, $pid = 0) {
+
if (comment_visible($comment, $threshold)) {
$output = '
$output .= theme('comment_view', $comment, '', 0);
?>
--
Axel,
www.axel.drupal.ru
Пара рабочих моментов:
1) При выборе текста, который пойдет на sabj, текст внутри quote должен игнорироваться.
2) Рубить лучше дождавшись пробела или перевода строки. Обкушенные слова смотрятся очень некрасиво.
3) А лучше всего рубить дождавшись точки с пробелом/переводом строки (т.е. конца предложения). Если не удалось их уместить в отведенную длину - ставить в конце выдранной цитаты многоточие.
Претензии к функции в сабже
Я просто её заюзал. Это друпаловская функция, которая для обрезки сабжей используется. Претензии к ней у меня тоже есть: желательно рубить по словам, а также выкидывать всё лишнее похожее на теги html (bbcode до кучи?) и переводы строк, которые всё равно какой-то хренью отображаются. Доберусь до неё как-нибудь ;E
--
Axel,
www.axel.drupal.ru
"Не повезло нам лишь с погодой, людьми, эпохой и страной!"(С)
Определённо, все дело в сабжектах!
--
Axel,
www.axel.drupal.ru
Можно плясать от плоской (читай - хронологически строго структурированной) модели форума, пытаясь найти внятные способы обозначения смысловой связи отдельных записей. Сложноватая задача, и наверняка разрешимая, но мне нравится задача обратная:
Можно плясать от древовидной (читай - структурированной по смысловому признаку) модели форума - находя способы обозначения хронологической последовательности, в которой добавлялись записи.
В последнем случае мне на ум приходит такое соображение:
Хронологическая последовательность легче подвергается визуализации, нежели смысловая - так как смысловых разветвлений у обсуждения может сколько угодно, а временная шкала для всех одна, нам только нужно ее внятно выразить.
К примеру, это может быть визуальное выделение отдельных записей разными оттенками цвета (чем новее запись, тем насыщеннее оттенок фона, на котором она выведена). В дереве с несколькими сотнями комментариев все самые новые комментарии будут визуально выделены ярким цветом. Причем раскраска может логически зависеть от множества разных параметров - от общего количества комментариев в дереве, от частоты добавления комментариев, от настроек пользователя - он может настроить расраску только тех комментариев, которые появились за последние N дней, не трогая те, что появились раньше.
Естественно, тему можно развить.