Всем привет!

Начинаю активно работать над новой версией Новой музыки. Основной упор буду делать на юзабилити. Все эти дизайнерские штуки никому не нужны, все хотят удобно пользоваться сайтом. Очень понравилась система уведомлений на Фейсбуке. Система отслеживает и уведомляет пользователей о новых комментариях на его пост (фотографию и т.д.) и на появление новых комментариев там, где он что-то комментировал. НУ ОЧЕНЬ УДОБНО помоему. Не надо рыться по сайту, искать кто где что написал…

Читать дальше →

Я долго думал над тем, как улучшить и упростить это меню с целью повысить юзабилити. И вот мои предложения:

Читать дальше →

Попробую бросить и свои 5 копеек. В жж есть такая милая функция, реализуемая с помощью дополнения к Firefox под названием LiveJournal Addons. Жмешь на квадратик и кат раскрывается без перехода по ссылке в новое окно. Сказать, что это удобно — ничего не сказать. Мелочь, а приятно. Собственно как оно выглядит:

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

Очень хочу, чтобы у проекта была своя багтрекинговая система. Как для движка, так и для модулей от любых разработчиков.
Постить баги в письмах, или в комментах — как то не пристало. К тому же амбиции здоровые у создателя. Выход на запад итд. Надо подтянуть этот момент, развиваться станет проще.

Сейчас, чтобы написать личное сообщение пользователю, надо совершить как минимум два перехода: в профиль пользователя, и оттуда — к форме написания сообщения.

По-моему, было бы удобно в форме комментирования добавить галочку «как личное сообщение». Улавливаете? При чтении комментов возникла необходимость связаться с автором лично, для этого как обычно нажимаем «ответить» возле его коммента, пишем сообщение, и отмечаем его «как личное», после чего это сообщение отправляется прямиком в инбокс автора комментария.

Если точно также ответить в главную ветку, то личное сообщение отправится в инбокс автору топика.

В движках форумов такая функция реализована давно, и, на мой взгляд, является очень полезной. Суть в том, чтобы выделять самые важные топики в конкретном блоге. На форумах это происходит путем их закрепления сверху над общим потоком тем, в ЛС для этого можно вынести блок в правой части, где выводить заголовки самых важных топиков блога.

Читать дальше →

Хочу предложить свои идеи для развития MVC/ORM.

Замечу, что исторически сложилось так, что MVC в LiveStreet весьма отличается от привычного представления в других фреймворках.
Модель здесь заменяется связкой модуль+сущность+маппер, причем, если сущность представляет из себя стандартный ООП-объект с набором свойств и методов, то модули и мапперы, это просто наборы функций для работы с определенными типами данных, что скорее похоже на библиотеки из структурного программирования, чем на стандартный ООП.
Я не возьмусь судить хорошо это или плохо, у меня есть лишь предложения о том, как можно воспользоваться этим для создания эффективных отношений между объектами (модулями).

Читать дальше →

Это здорово, что в версии 0.4.* появилась возможность автоматического доступа к полям модели из записи в БД, без постоянного прописывания get- и set-методов в файле *.entity.php.

Однако при попытке воспользоваться новым функционалом сразу столкнулся с проблемой:
Т.к. по логике, принятой в LS, все поля записываются в базе данных с префиксом (имя модели), то и автоматические геттеры теперь требуют имени модели.
Иначе говоря, если у нас есть модуль Test с таблицей prefix_test и полем в таблице test_name, то чтобы получить к нему доступ, нам нужно писать $oTest->getTestName() вместо привычного способа $oTest->getName(), который является логичным и удобным.

Я считаю, что необходимо ввести поддержку обоих вариантов, не только по причине неудобства варианта, который возможен сейчас, а еще и по более важной причине — совместимости.
Исторически в самом LiveStreet все методы были прописаны в *.entity.php и указывались без имени модели, например для блога — getDescription(), getTitle() и т.д., а никак не getBlogDescription() и getBlogTitle().

Подобный принцип наименования (вполне логичный и разумный) наследовали большинство модулей и плагинов, которые существуют на сегодняшний день, поэтому было бы совсем не разумно использовать половину методов (которые уже прописаны в *.entity.php) в одном виде, а другую половину, которая будет добавляться вместе с новыми свойствами моделей — в другом.

Предлагаю простой вариант, как исправить эту ошибку:
в /engine/classes/Entity.class.php, в методе __call()
после блока

if (isset($this->_aData[$sKey])) {					
  return $this->_aData[$sKey];
}

добавить блок

else {
  preg_match('/Entity([^_]+)/', get_class($this), $sModulePrefix);
  $sModulePrefix = strtolower($sModulePrefix[1]) .'_';
  if (isset($this->_aData[$sModulePrefix . $sKey])) {					
    return $this->_aData[$sModulePrefix . $sKey];
  }
}

На мой взгляд, это намного упростит и упорядочит работу с свойствами моделей.

Многие знают, что модуль Image отвечает за загрузку всей графики на сайт. Есть предложение для Максима, сделать его отдельным плагином, чтобы была возможность отключать, а так же осуществить поддержку загрузки gif анимации (аватары, фото и т.д.) и вывести под эту анимацию в конфиг плагина true/false.

Я полагаю многим сайтам эта опция будет полезна, а тем кому не нужна — отключат ее в конфиге.