Методы
Как-то сомневаюсь насчет get/set в нижнем регистре для сеттеров/геттеров.
Вообще, мне гораздо больше нравится для методов классов использовать lowerCamelCase. Но т.к. нам нужно использовать имена методов в «псевдовызовах» типа User_GetUsersByFilter(), то лучше, конечно, юзать UpperCamelCase (написание типа User_getUsersByFilter() — по мне как-то совсем не айс).
И в этих условиях выбирать регистр символов для разных случаев?
function GetUsersByFilter() { } // в модуле
function getUserName() { } // в сущности
Все ж правила должны быть более четкие. Я сам чисто по привычке и по предпочтениям своим нередко сбиваюсь на lowerCamelCase, но если уж мы о стандартах говорим, то нужен единообразный подход.
Итого, мое мнение: один из двух вариантов — либо во всех методах lowerCamelCase, либо — UpperCamelCase. Но «псевдовызовы» однозначно должны быть вида User_GetUsersByFilter()
Отлично! И название совсем не громкое, а вполне себе нормальное, как и должно быть. Зенды, правда, подобный документ называют Standard, но мы не будем так жестко, пусть будет Style, т.е. не жесткий стандарт, а рекомендуемый стиль.
Теперь по существу: все ж префикс переменной указывает на ее тип, а у мепперов и сущностей тип — object. Поэтому вводить специальные префиксы «e» и «m» вряд ли стоит, пусть для объектов будет только «o». Но можно допустить использование двойного (расширенного) префикса типа, если сильно хочется — «oe», «om». Тогда человек, не знакомый даже с документом, но знакомый с венгерской нотацией и типами данных в PHP, легко может догадаться, что это экземпляр объекта.
Очевидно, что движок не может по имени класса PluginContest_ActionContest_EventAdmin определить, где лежит файл с этим классом. Ибо не обучен. В ЛС как-то была добавлена поддержка ивентов в виде отдельных файлов, в Альто этого просто нет.
… несущая информацию о системе наименований переменных.
Нет, речь не просто о системе именования, а об Alto Coding Style.
У нас есть внутреннее соглашение о стиле кодирования, основанном на Zend Style, с некоторыми адаптациями под себя (та же венгерская нотация, например). Но хочется, чтобы это был открытый публичный документ, рекомендованный всем, кто пишет под Альто.
1 — ок, можно суффиксы и оставить, тем более, что они уже используются (я, правда, не догадывался, что это суффиксы и относился к переменным типа BlogNew так же, как к UserCurrent :)
Но, наверное, стоит тогда более четко их описать, составив примерный перечень.
2 — уже двое высказалось за разделение «n» на «i» и «f». Возможно, что стоит это сделать.
3 — да, аналогия с CMYK очень близкая :), пока не объяснишь — непонятно, но стоит объяснить — как правило, возражений не возникает. Для того и нужны четко прописанные рекомендации с пояснениями, к чему сейчас и идем. И, ИМХО, нужно, чтоб глаз цеплялся. Простой пример (не цитата из кода, но близко):
function GetTopicsByUser($xUser) { /* ... */ }
Тут $xUser может быть как сущностью, так и идентификатором, и очень важно, чтоб разработчик это сразу видел, что нужно обязательно проверить, что передано, прежде чем использовать.
По именование массивов (единственное/множественное число) — всегда колебался и не мог определиться, как лучше. Но высказанное предложение готов поддержать.
Насчет того, чтоб сущности обозначать префиксом «e», а все остальные объекты «o» — как-то даже и не знаю. Здравое зерно в этом есть. Но в то же время получается, что, хоть по сути своей entity — это object, но у нас o(bject) — это любой объект, кроме e(ntity). Поэтому хотелось бы выслушать мнения других разработчиков
Тема отличная. Я считаю, что определенный стиль кодирования — обязательная составляющая «эко-системы», которая выстраивается вокруг движка и уменьшает ее энтропию. А стиль именования переменных — неотъемлемая часть стиля кодирования. Поэтому предлагаю обсудить и выработать, наконец, четко сформулированные правила, которые в дальнейшем будут рекомендованы всем разработчикам на Альто.
Теперь по существу.
Suffix – семантический суффикс. Я бы предложил отказаться от семантического суффикса в именах переменных. Ну, или назвал бы его использование нежелательным. Например:
$oCurrentUser; // Это нормальное именование переменной без суффикса
$oUserCurrent; // А здесь то ли суффикс Current используется, то ли это плохое знание англ. языка
Префиксы числовых типов. Тотальное использование префикса «n» в числовых переменных, наверное, моя заслуга. Мне всегда казалось более разумным в языке без строгой типизации не разделять целочисленные и вещественные типы данных. В подавляющем числе случаев нам важно знать тип переменной, чтобы понимать, какие операции с ней возможно. И с этой точки зрения int и float идентичны. Но если это вызывает какие-то проблемы у разработчиков и они выскажутся за разделение на i/f — я возражать не буду.
Смешанный тип данных mixed. Та же история, что с «n» — префикс «x» введен с моей подачи. Я его всегда трактовал, как «miXed» :) Мне казалось, что этот префикс как-то более заметен глазом, чем «m», поэтому меньше вероятности ошибки из-за невнимательности.
Значит, надо удалить все накопленные ошибки (под списком ошибок кнопка «Удалить»), еще раз загрузить страницу, на которой выдается ошибка, и посмотреть журнал ошибок еще раз
1. Есть простое правило — для получения общедоступных данных надо юзать GET. К сожалению, движку в наследство от прародителя досталось бездумное использование POST, где следовало бы обойтись GET, а где-то — GET там, где меняются данные, и нужен POST.
Поэтому, чтоб решить проблему системно, на уровне движка, нужно провести ревизию запросов и упорядочить использование GET/POST. Но на это пока не хватает времени.
Чтоб решить проблему на конкретном сайте, нужно в тех запросах, где это не нужно, просто отключить проверку ключа сессиии, и все.
2. Если это так, то да, баг, проверим, и, если подтвердится, то пофиксим
Не-не-не, вот этого как раз и не нужно делать. Это я как разработчик aceAdminPanel и как соразработчик Альто говорю — не стоит экспериментировать с такой «гремучей смесью». )
Сходу не готов ответить, надо смотреть, тестировать. В принципе, записи вообще не должны удаляться, должна только сессия закрываться. Но, возможно, имеет место баг.
нажимаю при добавлении топика здесь на сайте кнопку «отправить» и проходит 30 секунд и более до того как топик будет опубликован
А вот это как раз понятно — задержка происходит за счет рассылки е-мейл уведомлений тем, кто подписался. Здесь они уходят сразу же, а не встают в очередь. Это решаемая проблема, только руки все никак не дойдут
Я лично на сегодняшний день не вижу серьезных проблем с производительностью Альто. Конечно, когда мы при разработке натыкаемся на явно узкие места в производительности, которые можно довольно быстро и просто расшить — мы это делаем. Но специально такой задачи себе не ставим. Основные усилия на данном этапе разработки направлены на безопасность, функциональность, гибкость, именно на этом делается упор.
Для примера — на этом сайте страницы генеряться примерно за 0.6 секунды. И это вообще без кеширования. Потребление памяти — менее 9 Мб. По-моему, вполне приемлемые значения.
Что касается тестов, то без конкретных цифр это выглядит как-то не очень. Особенно, когда встречается такое, что Альто оказался почти вдвое медленнее Инстанта, а потом вдруг «время генерации страниц у instanta в 3 раза меньше чем у alto». Т.к. вдвое или в три раза? Или скорость движка и скорость генерации страниц в Вашем понимании — это разные вещи?
Это позволяет, во-первых, заходить одному юзеру с разных устройств без разрыва «параллельной» авторизации. А, во-вторых, дает возможность просмотреть историю сессий пользователя (сразу оговорюсь, что пока такой «волшебной кнопки» нет — посмотреть историю сессий, но сама история есть, и поэтому добавить просмотр заходов — это дело техники)
Как-то сомневаюсь насчет get/set в нижнем регистре для сеттеров/геттеров.
Вообще, мне гораздо больше нравится для методов классов использовать lowerCamelCase. Но т.к. нам нужно использовать имена методов в «псевдовызовах» типа User_GetUsersByFilter(), то лучше, конечно, юзать UpperCamelCase (написание типа User_getUsersByFilter() — по мне как-то совсем не айс).
И в этих условиях выбирать регистр символов для разных случаев?
Все ж правила должны быть более четкие. Я сам чисто по привычке и по предпочтениям своим нередко сбиваюсь на lowerCamelCase, но если уж мы о стандартах говорим, то нужен единообразный подход.
Итого, мое мнение: один из двух вариантов — либо во всех методах lowerCamelCase, либо — UpperCamelCase. Но «псевдовызовы» однозначно должны быть вида User_GetUsersByFilter()
Теперь по существу: все ж префикс переменной указывает на ее тип, а у мепперов и сущностей тип — object. Поэтому вводить специальные префиксы «e» и «m» вряд ли стоит, пусть для объектов будет только «o». Но можно допустить использование двойного (расширенного) префикса типа, если сильно хочется — «oe», «om». Тогда человек, не знакомый даже с документом, но знакомый с венгерской нотацией и типами данных в PHP, легко может догадаться, что это экземпляр объекта.
Поставьте здесь рейтинг 1000, например, и все
С персональными немного сложнее, они вшиты прямо в движок, поэтому без шаманства никак. Был плагин для ЛС, который их отключает, можно попробовать
Не «несколько расширенный», а кардинально переработанный и улучшенный
У нас есть внутреннее соглашение о стиле кодирования, основанном на Zend Style, с некоторыми адаптациями под себя (та же венгерская нотация, например). Но хочется, чтобы это был открытый публичный документ, рекомендованный всем, кто пишет под Альто.
Но, наверное, стоит тогда более четко их описать, составив примерный перечень.
2 — уже двое высказалось за разделение «n» на «i» и «f». Возможно, что стоит это сделать.
3 — да, аналогия с CMYK очень близкая :), пока не объяснишь — непонятно, но стоит объяснить — как правило, возражений не возникает. Для того и нужны четко прописанные рекомендации с пояснениями, к чему сейчас и идем. И, ИМХО, нужно, чтоб глаз цеплялся. Простой пример (не цитата из кода, но близко):
Тут $xUser может быть как сущностью, так и идентификатором, и очень важно, чтоб разработчик это сразу видел, что нужно обязательно проверить, что передано, прежде чем использовать.
Насчет того, чтоб сущности обозначать префиксом «e», а все остальные объекты «o» — как-то даже и не знаю. Здравое зерно в этом есть. Но в то же время получается, что, хоть по сути своей entity — это object, но у нас o(bject) — это любой объект, кроме e(ntity). Поэтому хотелось бы выслушать мнения других разработчиков
Теперь по существу.
Suffix – семантический суффикс. Я бы предложил отказаться от семантического суффикса в именах переменных. Ну, или назвал бы его использование нежелательным. Например:
Префиксы числовых типов. Тотальное использование префикса «n» в числовых переменных, наверное, моя заслуга. Мне всегда казалось более разумным в языке без строгой типизации не разделять целочисленные и вещественные типы данных. В подавляющем числе случаев нам важно знать тип переменной, чтобы понимать, какие операции с ней возможно. И с этой точки зрения int и float идентичны. Но если это вызывает какие-то проблемы у разработчиков и они выскажутся за разделение на i/f — я возражать не буду.
Смешанный тип данных mixed. Та же история, что с «n» — префикс «x» введен с моей подачи. Я его всегда трактовал, как «miXed» :) Мне казалось, что этот префикс как-то более заметен глазом, чем «m», поэтому меньше вероятности ошибки из-за невнимательности.
Поэтому, чтоб решить проблему системно, на уровне движка, нужно провести ревизию запросов и упорядочить использование GET/POST. Но на это пока не хватает времени.
Чтоб решить проблему на конкретном сайте, нужно в тех запросах, где это не нужно, просто отключить проверку ключа сессиии, и все.
2. Если это так, то да, баг, проверим, и, если подтвердится, то пофиксим
Удаление юзеров в 1.0 будет
Для примера — на этом сайте страницы генеряться примерно за 0.6 секунды. И это вообще без кеширования. Потребление памяти — менее 9 Мб. По-моему, вполне приемлемые значения.
Что касается тестов, то без конкретных цифр это выглядит как-то не очень. Особенно, когда встречается такое, что Альто оказался почти вдвое медленнее Инстанта, а потом вдруг «время генерации страниц у instanta в 3 раза меньше чем у alto». Т.к. вдвое или в три раза? Или скорость движка и скорость генерации страниц в Вашем понимании — это разные вещи?
Число хранимых сессий одного юзера задается параметром конфига:
Если 0, то хранятся все сессии.
Это позволяет, во-первых, заходить одному юзеру с разных устройств без разрыва «параллельной» авторизации. А, во-вторых, дает возможность просмотреть историю сессий пользователя (сразу оговорюсь, что пока такой «волшебной кнопки» нет — посмотреть историю сессий, но сама история есть, и поэтому добавить просмотр заходов — это дело техники)