holfza

Во-первых, если вам нужно, чтобы проверки были независимыми, сделайте их независимыми. Сейчас ваш код читается как "если 1 то, иначе если 2 то, иначе если 3 то". Иными словами, уберите из логики "иначе".

Во-вторых, это хрень полная: $data['dopvopsuvsid'] == 3 || 4 || 5. Это условие всегда будет срабатывать, потому что 4 и 5 всегда будут приводиться к true. Либо пишите полное сравнение каждый раз, либо используйте in_array.

Напиши мини-скрипт на PHP, который запускается раз в сутки (Cron) и дописывает в текстовый файл рандомное число.

yiiframework.com

О блин, первый ответ меня убил. Каких еще умных слов напишут full-stack mega developers & super duper architectors, that have billion salary about that're using a lot of intellectual words.

Но опять же - вам куда? Я на своем уровне являюсь автомехаником, который пытается делать меньше, а чтобы работало дольше. И конечно, чтобы когда мне надоест, я мог любого, даже новичка нанять, и он посмотрев сутки понял - что тут и куда. И на выходе обычный сайт получится - который легко дорабатывается, и ломается на кусочки если надо.

Есть еще кодеры от слова "Тру", которые предпочитают новичку рассказывать три дня о том, как ставить "пакеты" и настраивать "зависимости" и что у них потом "приложение" даже получается, которое знай себе "Хелло, Ворлд!" выводит. И мы никогда не поймем друг друга.

Что до того, что начинать с CI глупо - тут да, они делали что-то очень простое но и в нем умудрились перемудрить. 10 конфиг файлов забитых какими-то редко-используемыми настройками уже о многом говорит.

Мне лично в фреймворке нужны:
** Простой роутинг - регулярки, в него сразу вкинуть обработку языков и обратную генерацию ссылок. Честно мне редко нужны были роуты в файле - я их всегда в базу перетаскивал, страницы создавать легче было в навикате, чем постоянно редактируя сначала роуты, потом контроллеры, потом создавая действия....
** Под этот роутинг разработанная исходная БД с языками (локалями), страницами (с путями к видам) и сессиями пользователей
** Вместо экшенов и контроллеров оставить одни только контроллеры, которые просто могут вкладываться друг в друга неограниченное число раз. Не забыть, что контроллеры нужна возможность хранить в разных файлах, в любой структуре папок
** Понятная система работы с БД и генерация кода моделей. Причем таким образом, чтобы генерировалась "исходная модель", а новую ты создавал на базе исходной, чтобы твои изменения каждый раз не затирались. Идеальная модель - это массив с заранее вбитыми в нее полями и дефолтными значениями. Обычный себе PHP массив. Главное, чтобы при выводе и работе с ним тебе не нужно сначала делать его массивом, чтобы просто удобно его просматривать.
** Есть такая практика - всю работу с моделью засовывать в модель. Ничего не могу сказать. Но для каждого модуля на сайте у меня всегда были собственные сообщения об ошибках. Поэтому реализовывать единую систему "валидации данных в модели", и потом сражаться с топорным:
Система сообщает:
1) Имя пользователя должно быть 1-30 символов
2) Имя пользователя не может содержать...
Зачем? Ошибки пишутся в самом модуле - если это модуль авторизации - напишите, что "Авторизация не удалась, введите так-то".
** При поиске с БД не забыть что иногда нужны а) связи и б) вложенные условия, соединяемые через И/ИЛИ
**
** Побольше разных наследований (в языках например - когда есть язык по умолчанию и есть несколько уровней на которых человек язык может выбрать - куки, база данных, программно-установленный, выбранный на сайте или введенный в адресную строку)
** Языки достаточно хранить в одном файле для каждого языка разделяя их через cat__lang и в формате json, чтобы легко подгружались из JS
** Модульность - это чтобы была возможность готовые библиотеки подключать быстро и легко, соответственно и писать их запросто
** Готовая авторизация (которая к слову занимает один файл в 200 строк, а не как у многих - сессии свои напишут, какие-то флеш сообщения напишут, "стэйты", а по итогу регистрацию все равно заново пиши)
** Ну при хороших раскладах конечно приятно иметь еще миграции всякие, для совсем уж крупных проектов, где базу удалить и закачать заново - работа двух дней

На что наплевать:
Комьюнити? В попу комьюнити. У вашего комьюнити каждый раз надо выпросить (читай - высосать, ублажить) желание помочь, ну или ждать по неделе, пока соблаговолите слезть со своих башен). О у меня даже было, один такой комьюнити-бой сказал - "я говорит, тебе не помогу, потому что мне не нравятся твои взгляды." Он полчаса учил меня жить, а в конце сказал, что у него нету 5 минут, чтобы просто сказать мне как делается то что я просил.

Документация? Ну как бы и да и нет. Если у тебя ф-ворк простой как бутылка - не надо писать эти километры и стены текста - кроме дрочева на них тех людей, кто любит все изучить и знать - толку не будет. На ф-ворке должны делаться простые операции, все остальное создается под заказ.

Встраивание в код всяких библиотек - бутстрапов разных, типа популярных, ангуляров и тд - в жопу. Кто хочет - добавит.

Сие должно получится настолько микроразмерным в плане кода, чтобы даже документацию писать не хотелось. Главное, не рассчитывать что ты покроешь все потребности аудитории. Скорее наоборот, нацеливайся, что ты дашь аудитории (к слову не всегда такой же тупой, как например, я) методику разработки приложений не используя те технологии, что они используют сейчас.

Идеальное бизнес-направление работы, это когда твоя система позволит новичкам быть такими же умными, как и профессионалы, потому что будет очень простая. И на этой системе всегда можно будет сделать чудеса, не обязательно за 5 минут, но используя те инструменты, что есть.

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

Just, be simple.

Хорошая документация

А вы байты считаете потому, что ваша программа будет работать на холодильнике?
Или, может, диапазонов у вас будут триллионы?
Или количество выборок будет миллиард в день?

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

Условно говоря, планка оперативки сейчас стоит соразмерно часу работы программиста. Поэтому, если вы при проектировании проекта потратили на час больше времени и сделали "оптимизированное" но неудобное решение, поддержка которого будет съедать еще по часу в месяц - вы оказали проекту медвежью услугу.
Сразу скажу, что я не призываю писать неоптимизированный говнокод и закрывать дыры в нем наращиванием железа. Но то, о чем вы говорите, даже экономией на спичках не назвать.

Потому что this в момент выполнения кода вряд-ли указывает на div.pop.

var $pop = $('div.dop');
$pop.myRat({'tekr': $pop.data('rat') });

Откройте консоль в браузере (F12) и посмотрите ошибки.

MVC вы нарушаете, если вы хотите вызвать контролер из контроллера.. сразу задумайтесь.. что у Вас не так...
все логику в Model, отображение в View )))

Мне очень нужно.

вам нужно вынести бизнес логику в сервисы и дергать ее из каких угодно контроллеров.

Дело в том, что вы обработчик удаления зачем-то ставите внутри обработчика добавления. Нужно делать так:

$('#add_form').click(function() {
    var i = ($('.form:last').attr('id') || 0) + 1;
    $('<div id="'+ i +'" class="form">\n' +
        '<input type="text" class="form_input form-control" " placeholder="Название формы"/>\n' +
        '<textarea class="form_input form-control" rows="5"  placeholder="Описание формы"></textarea>\n' +
        '<span class="remove_form btn btn-danger">Удалить форму</span>\n' +
        '</div>')
    .fadeIn('slow').appendTo('.all_form');
});

$('.remove_form').click(function() {
    if (confirm("Вы хотите удалить форму?")) {
        $(this).closest('.form').remove();
    }
});

P.S. Обратите внимание, я в вашем коде поправил еще некоторые странности.