Новая структура и новые конфиги

В движке наметились кое какие архитектурные изменения. А именно:
  • изменение структуры каталогов, вынос ядра в отдельный каталог
  • новая система конфигов через массивы
В корне движка появился каталог /engine/, он содержит все файлы относящиеся непосредственно к ядру(фреймворку) LiveStreet. Это придает гибкости при реализации нескольких проектов на одном ядре, а так же позволяет обновлять ядро независимо от проекта. Теоретически сам каталог /engine/ можно вообще вынести за пределы DOCUMENT_ROOT.
Новая система конфигов позволит гибко управлять ими из любой точки движка. Также появилась возможность легкого пользовательского переопределения конфига.

Все эти нововведения призваны расширить и в тоже время упростить работу с движком.

89 комментариев

avatar
Теоретически сам каталог /engine/ можно вообще вынести за пределы DOCUMENT_ROOT.

Не получится, там находится tiny_mce, которые должны лежать внутри DOCUMENT_ROOT. Остальное — да, можно и нужно.
Радует направление движения проекта в сторону создания универсального движка для практически любого функционала, спасибо!
  • AliG
  • 0
avatar
ну я специально для этого случая написал — Теоретически :)
в конфиге для этого появилась настройка — web путь до /engine/lib/. Это может быть как текущий сервер так и другой сервер, где доступ по http имеет только каталог /lib/. Есть разные варианты, по дефолту /engine/ будет лежать в корне проекта
avatar
ort, вы ознакомились с codeigniter?
  • vist
  • 0
avatar
тоже об этом подумал.
вчера вечером только думал — как бы убрать за корень папку с блогом.
avatar
нет
avatar
codeigniter очень простой и понятный фреймворк, советую для общего ознакомления!
avatar
но заточен под php4
avatar
И ооочень медленно движется вперед.

Если смотреть на CI, то лучше — KohanaPHP (это самостоятельная ветка CI), но тут обратная проблема — слишком быстрое развитие — дока сильно отличается от реального состояния вещей.
avatar
Угу, мне тоже Кохана понравился.
avatar
Чем он плох? тем что нету с каждым днем нового минирелиза и фиксов багов?
Неужели это плохо?! Это наоборот показывает что есть стабильность и уверенность в своих релизах. И девелоперы довольны.
НА ЦИ написано много крупнейших проектов с миллионной аудиторией. И все шустрит и без дыр.
Поэтому ЦИ — как по мне лучший выбор для разработчика кто не гоняется за «аля модными движками», а кто берет за основу качество, гибкость и легкость.
avatar
я бы сильно не настаивал на этом. так как заточка уходит с каждым релизом. остались модули написанные под пых 4. но многие вещи уже перешли на пых 5. так что дело времени.
avatar
А что вы имеете в виду? Разделения уровня core и уровня application? Так это почти во всех фреймворках реализовано. Только называется везде по разному.
avatar
Применительно к ЛС напрашивается даже не два, а три уровня:
ядро, реализующее модель MVC, промежуточный уровень, содержащий базовые модули (блоги, топики и т.д.), и собственно уровень приложения.
avatar
Тут вопрос скорее «Что считать приложением?» — если брать LS как движек — то приложение это и есть уровень базовых модулей. А то, что пользователь надстраивает — это уже вроде как не «приложение LS»…

А, вообще, при желании можно кучу уровней придумать :)
avatar
Попробую пояснить. Сейчас ЛС позиционируется, как «движок блогосоциальной сети». Собственно, развитие ЛС идет к тому, что это будет готовая система создания и управления сайтом — залил скрипты, настроил, натянул свой дизайн и получил готовый продукт. При желании (и умении) можно доработать кучу своих модулей.

Мне же кажется правильным из базового функционала ЛС выделить ядро — некий фреймворк, который сам по себе не является какой-то готовой системой, но которую реальные программеры могли бы использовать для создания любых своих проектов, в т.ч. и никак не связанных с блогами и проч.

Я, например, сейчас ковыряю ЛС именно с этой точки зрения — думаю, не сделать ли на его базе некий простой фреймворк. Иногда для какого-нить не шибко навороченного сайта всякие там Zend и CodeIgniter слишком навороченные и тяжелые. Чего из пушки по воробьям палить?
avatar
Я, например, сейчас ковыряю ЛС именно с этой точки зрения — думаю, не сделать ли на его базе некий простой фреймворк.
по сабжу это и произошло
avatar
тогда следующий шаг — рядом с папкой engine должна появиться папка типа app

«выпив прявитель, надо выпить и закрепитель — любой процесс должен быть завершен» (с)… :)
avatar
развитие ЛС идет к тому, что это будет готовая система создания и управления сайтом — залил скрипты, настроил, натянул свой дизайн и получил готовый продукт. При желании (и умении) можно доработать кучу своих модулей.


Я все же надеюсь, что позиционирование сохранится… В специализации сила.
avatar
Я тоже на это надеюсь. Я лишь предлагаю архитектуру движка структурировать. Но, похоже, в этом направлении работы идут.
avatar
С этим согласен :)
avatar
Скажите а в данный момент последний релиз рабочий, можно ставить?

И возникает вопрос что будет с платными модулями, который куплены и поставлены на 0.3.1. их сильно придется переделывать, чтобы заработали на будущей версии 0.4 финал?
avatar
Скажите а в данный момент последний релиз рабочий, можно ставить?
можно для экспериментов
avatar
Насколько сильно и повлияют ли вообще архитектурные изменения на совместимость с платными и бесплатными модулями?
avatar
Ну, право, смешно, когда идет такое подчеркивание — «платные/бесплатные». С точки зрения архитектуры системы разве есть какая-то разница, за деньги модуль был написан или «за так»?

А вообще, я думаю, что изменения повлияют сильно. Насколько сильно — это будет ясно, когда будет релиз. Я по своим модулям могу сказать — вряд ли они будут работать в новой версии вообще без изменений.
avatar
Да это я так для связки слов брякнул:)… понятно что системе пофиг платный модуль или бесплатный. Буду надеяться, что авторы модулей обновят их до совместимости с новой версии LS.
avatar
Вот блин, вроде движемся фпиред.
Но что как-то от ваших слов не шибко спокойно.
Щас собирать сайт на 0.3.1, дописывать функционал, ставить платные модули, допиливать функционал этих модулей и самое главное вкладывать денежку.
Спустя какое-то время все сначала.
Вот блин… ))) как быть?
avatar
Ну, так ведь версия 0,3x.
Вот до единицы дойдет — тогда, думаю, не будет так круто меняться. А пока это неизбежно и даже благостно.
Ребенок, когда растет, одежду тоже новую часто покупать приходится. :)

Я пока сайт на 0,31 сделал и «обвеску» самую минимальную провел. Честное слово, большинству сайтов шибко много и не надо, если разобраться. Так что у меня переезд пройдет легко.
avatar
Вот если б еще от шаблонизатора абстрагироваться — ваще классно будет.
avatar
Это было бы вообще супер!
avatar
Кстати только щас заметил, а движок уже напару апгрейдится?!
ort и kachayev, т.е. движемся в два раза быстрей. ;)

или это временно?
avatar
kachayev был принят на работу в LS. Теперь будем работать активнее.
avatar
Эта радует!
avatar
Четыре руки хорошо, а две головы еще лучше :)
avatar
Еще предложения по развитию:

1) Добавить расширенные правила роутинга. Сейчас задается жесткая связка — site.com/route/ => ActionSomething.class.php. В идеале было б классно, если б route можно было бы задавать регэкспом. Или (если это покажется расточительным), хотя бы в виде site.com/route*/ => ...

2) Предложение спорное, но все же озвучу: изменить терминологию. По сути, то, что сейчас называется Action — это Controller. Роутер — он и есть роутер, который определяет, какому контроллеру передать на обработку урл. Во всяком случае в больших фреймворках подход как раз такой. Я понимаю, что это вызовет дополнительные проблемы с совместимостью версий 0.3 и 0.4, но раз все равно их не избежать, может, стоит пойти на такой шаг?
avatar
Я тоже после 3х лет Zend Framework`а долго привыкал к разделению action\event :)

По роутингу: евенты сейчас и так можно определять регэкспом. А нужно ли регексп для определения Action`а — тут спорный вопрос. В таком случае роутер вообще нужно расширять — по аналогу зендовского — переносить на него задачу распределения не только Action (читай Controller), но и Event (читай Action). Естественно, это даст больший просто для действий, но со своими проблемами.

На заметку: работа роутера на svn поменялась — подстроена под новые конфиги. Теперь в роутер введено понятие внутреннего Rewrite, и из шаблона убраны все константы, адреса определяются через smarty-плагин (я описывал в одной из своих заметок, с небольшими изменениями). Теперь можно без проблем менять адресацию во всем проекте одной строчкой кода. Т.е. работы в этом направлении ведутся.
avatar
Я тоже после 3х лет Zend Framework`а долго привыкал к разделению action\event :)
Да дело, в общем-то, не в привычке, я как-то легко въехал. Дело в том, что разбивка урла на /controller/action/params/.../ или /controller/function/params/.../ стала, по-моему, уже стандартом де-факто. Во всяком случае, это именно так у трех фреймворков, которые я смотрел — Zend FW, Kohana и CodeIgniter.

А по поводу роутера — переносить на него распределение Event (по-нонешнему) не стоит. Тут у ЛС как раз бОльшая гибкость, что мне лично импонирует. А вот насчет регекспа Action — конечно, вам решать. Но мне бы хотелось. :)
avatar
В Zend`e роутер по умолчанию работает /:module/:controller/:action/:param1/…
Где module — это типа «application внутри application». Во многом отсюда в MVC терминологию перешло понятие Module, которое представляет из себя некую инкапсулированную mvc-связку. В LS мы под модулем понимаем совсем другое :)

Т.е. по вопросам имен и терминов можно долго разбираться — смотря как глубоко копать в эту тему.
avatar
Ладно, оставим термины. Глянул щас новый конфиг. И два вопроса:

1) Если роутинг остается «прямым» (т.е. без всяких регекспов и прочих заморочек), то для чего нужны определения типа $config['router']['page']['error'] = 'ActionError';? Уж тогда надо сделать автоопределение, чтоб страница /error/ автоматом отдавалась классу ActionError. Т.е. если нет явного объявления, то распределение идет автоматом. И для кастомных модулей не надо будет писать лишний файл config.route.php с одной строкой, а системе не надо будет инклудить лишний файл.

2) Меня и в текущей версии жестоко обламывает относительная папка /uploads. В новой версии, судя по конфигу, она также будет относительной? Что мешает ее сделать абсолютной?
avatar
1. Этот вопрос обсуждается. Мое видение — $config['router']['page'] — должен быть по умолчанию пустым, как и ['rewrite']. Но функционал за ним все равно должен оставаться, на случай, если пользователю понадобиться использовать кастомный Action, или вообще что-то самописное.

Т.е. пользователь написал свой Action для отображения блога и поставил —
$config['router']['page']['blog']='ActionMyCoolBlog'

А потом еще и захотел, чтобы доступ к нему был не через /blog/, а через /superblog/ — добавил
$config['router']['rewrite']['blog']='superblog'


Помимо удобства здесь есть еще одно преимущество — конфиг роутера теперь можно «перекрыть» из конфига модуля. Т.е. можно писать модули, которые будут «подменять» стандартные action`ы в автоматическом режиме, без необходимости вносить правки в основную конфигурацию.

а системе не надо будет инклудить лишний файл

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

2. Масштабируемость. Сколько контента вы уместите в одном каталоге?

Пока в этом направление ничего не реализовано, но плацдарм готов — /uploads не имеет жесткой привязки, может быть сменена через Config::Set()… Пишите мини-файловый-сервер, распределяющий и тянущий контент с разных серверов, если на одном места не хватает.

LS по своей специализации должна быть максимально просто масштабируемой, иначе ваше «блого-социальное сообщество» быстро разрастаясь наткнется на серьезные технические трудности.
avatar
1. Собственно, это я и имел ввиду — либо пустым, либо вообще отсутствовать, тогда роутер отрабатывает его так же, как если б он пустым был. А то, что есть возможность переопределения — это однозначно зер гут.

2. Ты не понял — в версии 0.3 константа DIR_UPLOADS содержит относительный путь, и в некоторых базовых модулях при обработке путей к нему явным образом лепится DIR_WEB_ROOT (типа $path=DIR_WEB_ROOT.DIR_UPLOADS). Поэтому, переопределив его в конфиге и задав абсолютный путь, мне надо еще лезть в базовые модули, чтоб это убрать. Но по ответу я понял, что в новой версии таких проблем быть не должно, и я могу задавать для upload любые пути, в т.ч. и абсолютные.
avatar
1. тогда при запросе любого урла(например, /blabla/) придется всегда смотреть существование файла ActionBlabla, что также не хорошо
avatar
Или загружать список существующих Actions при инициализации роутера (или при загрузке конфигов)…
avatar
придется считывать листинг каталога при каждом обращении к сайту, это не лучше чем проверять на существование. Тем более если учесть, что в среднем наиболее часто за одно обращение используется один экшен
avatar
А вот тут я предлагаю более активно использовать кеширование. Я знаю, про isFileExists, но предлагаю копнуть глубже и обернуть функции и чтения каталога, и проверки файла в некий класс. В классе задать перечень папок, к которым мы точно знаем, что часто обращаемся, и содержимое которых надо кешировать.

Тогда при первом обращении к папке, например, /actions или /modules (пусть это даже просто наличие проверки файла) мы считываем ее содержимое и засовываем в мемкеш (если он включен, ясень пень кешировать в файлов кеше смысла нет). Также сохраняем массив с содержимым папки в свойстве oEngine. Тогда при последующих обращениях к этой папке в рамках обработки одного урла мы вообще больше файловую систему трогать не будем. А так — будем дергать данные из кеша. Т.е. по сути, двухуровневый кеш получается.

Единственная проблема, которую вижу сходу — это добавление модулей, изменение конфига (его тоже через этот алгоритм гнать надо) и т.д. Но решается она довольно просто — предусматриваем экшн /restart/, который необходимо вызывать под админом после каких-то изменений, и который будет сбрасывать все кеши.

ЗЫ. Ребят, ничего, что я вам тут все советую? Не очень достал? ;)
avatar
что касается isFileExists, то опытным путем её использование не дает прироста скорости как при файловом кеше так и при мемкеше, работает начинает даже чуть медленнее. Проблема скорее в том, что реальная польза от этого метода будет только тогда, когда производительность системы начинает упираться в жесткий диск, а 99.99% сайтов это не грозит
avatar
Кстати, можно еще задать REST как стандарт разработки для основных ресурсов… Сильно удобно.
avatar
И еще предложение: отказаться от перечисляемых типов в полях таблиц БД. Например, типы блогов и типы топиков — если я делаю новый тип, то надо менять (хоть и незначительно) одну из базовых таблиц. Гораздо лучше и гибче будет, если типы будут лежать в отдельной таблице, тогда создание своего типа — это лишь добавление записи.
avatar
Зачем городить абычо? Часто вы создаете новые виды топиков, три раза на дню?
avatar
Дело не в частоте создания новых типов топиков, а в гибкости и в совместимости разрабатываемых модулей. Таблицы prefix_blog и prefix_topic — базовые таблицы движка, а поля blog_type и topic_type — базовые поля этих таблиц (т.е. сущности, которые изначально генерятся в БД). И если я при разработке модуля меняю базовые вещи — это совсем не есть гуд.

Элементарный пример — я разработал модуль работы с новым типом топиков (или блогов). Для этого расширил перечисление типов, добавив тип «avadim». Кто-то другой пишет свой модуль с другим типом топиков, добавив тип «drugoi». Если юзер захочет поставить оба модуля, он должен будет руками залезть в базу и создать свой перечисляемый тип, который будет содержать оба типа топиков — «avadim» и «drugoi»! А потом разработчики ЛС добавят новый базовый тип, и при очередном апгрейде движка все, что добавил в базу юзер, будет почикано.

Оно вам надо такой гемор?
avatar
Если юзер захочет поставить оба модуля, он должен будет руками залезть в базу и создать свой перечисляемый тип, который будет содержать оба типа топиков — «avadim» и «drugoi»! А потом разработчики ЛС добавят новый базовый тип, и при очередном апгрейде движка все, что добавил в базу юзер, будет почикано.
если честно то не понял. Вроде как при изменении ENUM данные в таблице сохраняются, а получить текущий список значений можно так:
DESCRIBE `prefix_topic` `topic_type` 
avatar
Объясняю на конкретных примерах. Я хочу добавить новый тип блога 'avadim'. Значит, где-то (либо при установке, либо еще где) я добавляю sql-запрос:
ALTER TABLE `zls_blog` CHANGE `blog_type` `blog_type` 
ENUM( 'personal', 'open', 'invite', 'close', 'avadim' ) DEFAULT 'personal'

Другой разработчик тоже создает свой тип блога 'drugoi'. И что он делает?
ALTER TABLE `zls_blog` CHANGE `blog_type` `blog_type` 
ENUM( 'personal', 'open', 'invite', 'close', 'drugoi' ) DEFAULT 'personal'

И если юзер надумает поставить сначала мой модуль, а потом другой, то мой, естественно, работать перестанет. Что нужно будет сделать юзеру, если он захочет использовать оба модуля? Руками править таблицу, чтобы там оба эти типа жили.

А потом вы решите добавить новый тип блога, например, 'hidden'. И вы вряд ли станете анализировать, менял ли юзер одну из базовых сущностей в таблице или нет. Вы просто сделаете патч, где будет следующий код:
ALTER TABLE `zls_blog` CHANGE `blog_type` `blog_type` 
ENUM( 'personal', 'open', 'invite', 'close', 'hidden' ) DEFAULT 'personal'

Юзер накатит ваш апгрейд и убъет два своих модуля, пока опять не полезет в базу руками.

И, кстати, получение списка типов через SELECT (если их задавать в отдельной таблице) гораздо проще, чем получать список полей через DESCRIBE, а потом еще и парсить строку типа «ENUM('aaa', 'bbb', ...)».

Нет, если установка жесткая — «в ЛС возможны только те типы блогов и топиков, которые предусмотрели разработчики», то все ок. Если же декларируется, что разработка своих типов возможна без хаков и ковыряния в базе, то стоит подумать над этим.
avatar
сначала спросил
И если юзер надумает поставить сначала мой модуль, а потом другой, то мой, естественно, работать перестанет. Что нужно будет сделать юзеру, если он захочет использовать оба модуля? Руками править таблицу, чтобы там оба эти типа жили.

потом сам ответил
получать список полей через DESCRIBE

как делать парсинг строки могу показать :)

я к тому, что есть задача — добавить тип, есть стандартное и существующее решение, которое никого не ограничивает и позволяет манипулировать с типами. Зачем придумывать дополнительное решение, которое добавляет новые таблицы и дополнительные запросы(джойны) при выборке?
avatar
Зачем придумывать дополнительное решение, которое добавляет новые таблицы и дополнительные запросы(джойны) при выборке?
Выше я постарался объяснить, зачем. Будем считать, что мои доводы были не убедительны.
avatar
твои доводы о проблеме, когда юзер ставит себе несколько разных модулей, добавляющих новые типа, не состоятельны при использовании DESCRIBE. Так?
avatar
Я не говорил «не состоятельны», я сказал «не убедительны». Для тебя. Причем, установка несколькоих модулей — это лишь пример одной из проблем, которая может возникнуть.

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

Мое мнение: если установка модуля сопровождается созданием новых таблиц — это нормально. Если при этом требуется добавлять поля в базовую таблицу — это уже не очень хорошо. Если при этом меняется какое-то базовое поле — это уже совсем нехорошо. Вот просто по определению. И неважно, чего меняется и как. Просто надо стараться всеми силами этого избегать. Если в терминах ООП, то это все равно, если б я:
а) сделал расширение класса — ок
б) добавил свойство или метод в базовый клас — не очень ок
в) изменил свойство или метод в базовом классе — совсем не гут.

«Я ясно излагаю?» (с)…

ЗЫ Прошу понять правильно — я не пытаюсь тебя «переломить через коленку», лишь хочу, чтоб ты понял мои доводы. При этом не обязательно их принимать — степень их убедительности и значимости ты определяешь сам. :)

ЗЗЫ Кстати, если позволить себе некоторую избыточность, то можно не плодить новых джойнов. Не очень правильно с академической точки зрения, но «если нельзя, но очень хочется, то — можно» :)
avatar
ясно
avatar
это уже не очень хорошо

ну пока многие задачи которые нужны пользователям ls (сюда по топикамкак сделать то-то) решаются только изменением, добавлением полей, про тип топика все ясно, ксати вопрос к ort, может допускать в каталог модулей только те, которые работают хотя бы с базой по стандартам (та же проверка на типы поля)?
avatar
к выходу 0.4 попробуем унифицировать/стандартизировать модули, так и усилить контроль кода
avatar
Это было бы хорошо, но что если после 0.4, к 0.5, снова появятся какие-то новые коренные изменения в структуре?

Я ещё не успел ознакомиться подробно со всеми нововведениями, но уже сейчас по отзывам других пользователей сделал вывод, что перенос модулей на новую структуру будет очень трудоёмким. В связи с этим нужно единогласно решить, когда выйдет версия с окончательно проработанной структурой ядра, чтобы можно было спокойно провести рефакторинг всех существующих модулей.

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

Так же скорее всего придется отложить запуск проекта, буду ждать новый релиз. А пока займусь дизайном.
avatar
нужно единогласно решить...
Ну это совсем не серьезно. Это типа мы щас тут все посоветуемся и проголосуем, и дадим Максу план развития его движка? )))

Я думаю, при всем желании вряд ли кто может «зуб пацана дать», что больше серьезных изменений в архитектуре не будет. И не потому, что легкомысленно к этому относятся, а в силу того, что чрезвычайно сложно заранее все нюансы предусмотреть. Как было сказано в параллельном топике — проект еще слишком молод и слишком динамичен, чтоб можно было говорить об окончательно устоявшихся стандартах.
avatar
прошу прощения, на самом деле, совсем другое имел ввиду (3 часа утра оказывают влияние :))
но я думаю, что мысль в целом ясна. вопрос скорее напрямую к ort`у: какие действия могут быть предожены разработчикам модулей на данный момент? с учетом проведенного рефакторинга и возможных дальнейших модификаций ядра.
avatar
Ну не могу удержаться — еще предложение. :)
В новом варианте конфигурирование модуля выглядит так:
$config['sphinx']['host'] = 'localhost';

Думаю, лучше сделать так:
$config['modules']['sphinx']['host'] = 'localhost';

Мелочь, конечно, но более структурировано получается
avatar
Может вам устроиться в разработчики ls?
Мне кажется создание новой версии будет намного быстрее!
Тем более вы хорошо знакомы со структуров и «что нужно пользователям»…
avatar
Судя по дискуссии будет тогда файтинг )))
avatar
Во-первых, я решил воспользоваться возможностью понять точку зрения разработчиков на внутренне устройство движка. А во-вторых, высказать какие-то свои соображения. Если разработчикам они покажутся важными — они их примут, нет — останутся при своем мнении. В любом случае, мне кажется, разговор интересен. Во всяком случае, мне :)

И ваще, надо уметь отличать нормальную дискуссию от мордобоя :)
avatar
Повнимательнее изучите конфиг. Для наглядности просто выведите его на печать print_r(Config::Get()).
$config['entity_prefix']  = '';
$config['sphinx']['host'] = 'localhost';
$config['sphinx']['port'] = '3312';

определено в файле /config/modules/search/config.php — т.е. это конфигурация модуля. При отработке /config/loader.php этот массив будет слит в конфиг с префиксом 'module.название_модуля'. В итоге получим на выходе (кусок конфига):

[module] => Array
        (
            [blog] => Array
                (
                    [per_page] => 20
                    [personal_good] => -5
                    [collective_good] => -3
                    [index_good] => -8
                )

            [topic] => Array
                (
                    [new_time] => 86400
                    [per_page] => 10
                )

            [user] => Array
                (
                    [per_page] => 15
                )

            [comment] => Array
                (
                    [per_page] => 20
                    [bad] => -5
                    [max_tree] => 7
                )

            [autoLoad] => Array
                (
                    [0] => Cache
                    [1] => Session
                    [2] => User
                    [3] => Lang
                )

            [search] => Array
                (
                    [entity_prefix] => 
                    [sphinx] => Array
                        (
                            [host] => localhost
                            [port] => 3312
                        )

                )

        )
avatar
Все понял, разумно сделано. Вопрос снят
avatar
я может что-то не то спрошу, но, зачем были запилены красивые 404 страницы?
if (isset($aError[0]) and $aError[0]['title']=='404') {			
			header("HTTP/1.1 404 Not Found");
		}
avatar
не понял вопроса или «что-то не то»
avatar
хм… странно вчера смотрел в денвере и на ie, так вот получив в хидере 404 браузер показывал стандартную 404, правда ночь уже была, наверно чтото не доглядел)
avatar
Да, и вот главный [вопрос, совет, глупый вопрос] почему бы не формировать страницы для аякса тем же смарти? создать шаблон xml и стучатся на тотже /action_route/event_ajax, с точки зрения разработчика было бы гораздо удобнее иметь всю логику экшена в одном месте.
Лично я когда разбирал ls 0.2 на фреймворк и ЦМС имеено так и реализовал, на мой взгляд стало удобнее…
avatar
версия из транка это поддерживает, может отдавать респонс как в формате json так и от ДК-лаб. Сейчас так работает добавление комментариев.
avatar
Вообще, конечно хорошо бы иметь возможность вернуть и то и другое…

Например, когда мы постим ajaxом топик, возвращается html главной (который подгружаем тем же шаблоном, что и обычно, только без хидера/футера) и json, который мы обрабатываем и задаем классы элементов, который на странице.
avatar
Еще момент в экшенах идекса или блога считаем количество новых топикво в Инит()

$this->iCountTopicsPersonalNew=$this->Topic_GetCountTopicsPersonalNew();	
$this->iCountTopicsBlogNew=$this->iCountTopicsCollectiveNew;
$this->iCountTopicsNew=$this->iCountTopicsCollectiveNew+$this->iCountTopicsPersonalNew;

и потом в shutdown() отправляем переменные в шаблон, а в экшене персональных блогов и топ считаем все в shutdown(), может все одинаково сделать, дабы не вводить общественность в заблуждение?
avatar
Если общественность понимает смысл этих строк, то вряд ли это введет их в заблуждение. А если нет — на нет и суда нет.
avatar
ну о зачем одну и туже операцию делать по разному? Переменные эти нигде более как в шаблоне не используются экшеном…
avatar
Во-первых, могут использоваться. Если даже в этих экшенах не используются, то в других — могут вполне.

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

И, повторюсь, это может ввести в заблуждение только ту общественность, которая совешенно не понимает смысла этих строк.
avatar
И, повторюсь, это может ввести в заблуждение только ту общественность, которая совешенно не понимает смысла этих строк.
забудьте про общественность)
Речь за то что по сути 4 экшена очень схожи между собой они достоют все топики новые, новые коллективные топики, новые персональные топики и топ, переменные о которых мы говорим определяют количество оных, для «рисования +n» в меню. В первых двух экшенах реализовано это УДОБНО я могу использовать переменные в любом методе, т.к. они являеются свойством класса, а других же двух этого не сделано, почему бы не потратить 5 минут и не сделать коммит который это исправит, к томуже пока ls это блогосферная соцсеть — эти экшены неотъемлемые части ls, и воевать за красоту кода в них необходимо.
avatar
kcaptcha осталась в папке engine, и естесвено не доступна в регистрации т.к. там написано через classes, может ввести еще одну переменную в конфиге $config['path']['root']['engine_web']? и по этому пути поселить и тинимайс, а потом смело вынести всю engine за предели DOCUMENT_ROOT
avatar
ну или хотябы в actions/ActionRegistration/index.tpl поправить на
{$aConfig.path.root.engine_lib}/external/kcaptcha/index.php?{$_sPhpSessionName}={$_sPhpSessionId}
avatar
предлагаю перед тек как писать заглядывать в SVN
avatar
оперативно) не успеваю следить за изменениями
avatar
я так понимаю, последней «стабильной» ревизией, с которой можно рассчитывать работу модулей можно считать #402?
avatar
пока такой ревизии нет, но в ближайшие неделю-две должна появиться
avatar
хорошо, ждём
avatar
если что, я имел ввиду последнюю ревизию до рефакторинга, т.е. ту, на которой по идее должны работать все модули, как и раньше.
avatar
Афиша когда будет под 0.4?
avatar
Шаблон developer будет развиваться?
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.