Ох, вы знаете, вы многое написали и бестолку, честное слово, много воды, демагогия. Я изучал код движка (с PHP вообще не знаком, но прекрасно понимаю) да у меня были кое какие притензии, но я их уже изложил и Макс добавил недостающий функционал.
Зачем городить огромный огород с выводом с использованием смарти, xslt и т.д. Вы ведь Фаулера читали, я уверен, помните что он писал про гибкость? Не дословно, но: делая проекты архитектурно очень гибкими, со временем вы можете прийти к тому, что вам попросту не нужна вся эта гибкость.
И тут я с ним согласен, красивую и отточенную до самой маленькой сущности можно разрабатывать годами, а функционал нужен сейчас. Код у движка очень аккуратный, никаких выводов напрямую из глубины движка в view нет.
1) Завести еще одну переменную USER_USE_LOGIN для того, чтобы сделать сайт закрытым. И чтобы на него могли заходить только зарегистрированные пользователи. Так как сейчас сделано при инвайте.
Т.Е.:
true — на главной заглушка с логином и паролем.
false — доступ ко всему сайту.
2) Внести изменения в USER_USE_INVITE, чтобы эта переменная активизировала регистрацию на сайте только по инвайтам.
Т.Е.:
true — возможности просто зарегистрироваться нет. При регистрации на странице /registration/ нужно указать код регистрации. При регистрации человек становится автоматически другом того, кто дал ему этот код.
false — возможность просто зарегистрироваться.
3) Интересно было бы также отслеживать кто кого привел на сайт по средствам инвайтов.
Знаете скажу так, у самого, как разработчика, времени очень мало, это я так заскочил, когда анализировал движок (с точки зрения маркетинга, надо всегда быть в курсе событий), высказал свое имхо, если интересно разработчику LS я могу дать свой ICQ. Но могу сказать, что архитектура уже «установилась», поэтому тяжело будет что либо переделывать, надо уже как-то с этим жить :) для этого надо подпригаться под устновившуюся архитектуру и более глубоко изучать чужой код, для этого надо слышать самого разработчика, чтобы не искать фонариком иголку в темной комнате.
Я смотрю вы всё построили на событиях, с этой точки зрения правильно и по другому не сделаешь.
Но если идти по другому пути (гибкомти и унификации, то надо свовершенно координально идти другим путем, я пошел по пути иерархии правил (которые обрабатывает единый контроллер).
Получилось очень гибко и самое главное просто для юзера, единственное разработчику (мне) было тяжело :) Теперь практически любую задачу можно сделать правилами. При такой архитектуре даже голосования можно не делать как мсобытия и модулем. Обычный иерархический контент с минимальными правилами.
Я вот все это читаю, понятно, что вы хотите внести вклад в развитие ЛВ, ну так тогда нужно меньше слов — больше дела. Связывайтесь через асю, скайп с разработчиком и там уже обговаривайте и ДЕЛАЙТЕ улучшения. А так получается слова, брошенные в пустую, ни что иное, как треп…
Не увидел иерархии сущностей и обьектов, может я не досмотрел чего-то. После обработки контроллером иерархических входящих данных, далее легче обрабатывать модулями и легче подготовить данные к выводу.
Просто работая над своим проектом, анализируешь другие и когда видишь «ошибки» у колег, хочется помочь.
Я специально в ковычки поставил «ошибки»… с точки зрения специальзировано заточенного движка это можно назвать и не ошибками, но с точки зрения гибкости это уже можно назвать ошибками… но ошибками не в коде, а архитектуре (что кстати печальнее, так как надо много перерабатывать)
есть переменные, есть инструменты примитивной логики в шаблоне, что еще нужно? В любом случаи в итоге будет шаблон содержащий переменные(либо какие либо идентификаторы, XSLT муть) и логический код
выводить print («Привет») в коде ядра — это явное зло.
Надо передать «данные», описаные в API обработчику на вывод этого «привет», где обработчик должен знать тему не только для сайта и знать тему для модуля и т.п.
везде где есть вывод данных он должен «уходить» на обработчик вывода, где должен быть сразу продуман унифицированный механизм вывода. Тогда юзеру будет легко «натягивать» шаблоны
как ты представляешь возможным создать шаблон без вставок кода? Если только хоумпэйдж без логики
загляни в любой движок(цмс, форум и т.п.) везде есть код
Зачем городить огромный огород с выводом с использованием смарти, xslt и т.д. Вы ведь Фаулера читали, я уверен, помните что он писал про гибкость? Не дословно, но: делая проекты архитектурно очень гибкими, со временем вы можете прийти к тому, что вам попросту не нужна вся эта гибкость.
И тут я с ним согласен, красивую и отточенную до самой маленькой сущности можно разрабатывать годами, а функционал нужен сейчас. Код у движка очень аккуратный, никаких выводов напрямую из глубины движка в view нет.
1) Завести еще одну переменную USER_USE_LOGIN для того, чтобы сделать сайт закрытым. И чтобы на него могли заходить только зарегистрированные пользователи. Так как сейчас сделано при инвайте.
Т.Е.:
true — на главной заглушка с логином и паролем.
false — доступ ко всему сайту.
2) Внести изменения в USER_USE_INVITE, чтобы эта переменная активизировала регистрацию на сайте только по инвайтам.
Т.Е.:
true — возможности просто зарегистрироваться нет. При регистрации на странице /registration/ нужно указать код регистрации. При регистрации человек становится автоматически другом того, кто дал ему этот код.
false — возможность просто зарегистрироваться.
3) Интересно было бы также отслеживать кто кого привел на сайт по средствам инвайтов.
Кому интересно пишите в pm.
Но если идти по другому пути (гибкомти и унификации, то надо свовершенно координально идти другим путем, я пошел по пути иерархии правил (которые обрабатывает единый контроллер).
Получилось очень гибко и самое главное просто для юзера, единственное разработчику (мне) было тяжело :) Теперь практически любую задачу можно сделать правилами. При такой архитектуре даже голосования можно не делать как мсобытия и модулем. Обычный иерархический контент с минимальными правилами.
Я специально в ковычки поставил «ошибки»… с точки зрения специальзировано заточенного движка это можно назвать и не ошибками, но с точки зрения гибкости это уже можно назвать ошибками… но ошибками не в коде, а архитектуре (что кстати печальнее, так как надо много перерабатывать)
фактически «команды вывода для обработчика данных»…
вообще на пальцах тяжело обьяснить...:(
Вы в Москве живете?
выводить print («Привет») в коде ядра — это явное зло.
Надо передать «данные», описаные в API обработчику на вывод этого «привет», где обработчик должен знать тему не только для сайта и знать тему для модуля и т.п.
«Я немножко не то имел ввиду. Просто мне больше нравится, когда в шаблонах код выделен <?php ?> :))»
загляни в любой движок(цмс, форум и т.п.) везде есть код