Еще хотел бы спросить. Есть мысль открыть исходные коды всего проекта. На мой взгляд плюсом будет возможность привлечения людей учавствующих в разработке. Будет больше находится багов. Чаще исправляться. Ваше мнение. Стоит оно того?
У автора не работает enter?) Зы: все данные полученные от пользователя надо проверять на наличие спец символов, обрезать лишние количество полученных символов,не юзать злой глобалс и т.п.) может я конечно не прав, я сам пока ышо нуб)
Если открыть может и покажут в каком месте код говно. Если код говно тем более стоит открыть. Зачем говно скрывать?
Если скрывать то всегда в говне сидеть. Должен же кто то более умный показать на мои недостатки. Итак встречайте тонны моего ГОВНОКОДА. ftp://mpak.su
Продуктивного разговора не получится если мы сорказничать будем. Выражайся понятным языком. Сложно за 10 минут дать правильную оценку тому то писалось несколько лет. Если не понравилось то скажи что и почему? Может есть более эффективные решения. То что было хорошо в 2000 и сейчас не плохо. Хороший код оттачивается даже не годами а десятками лет. А в том что я сделал даже не код важен а сам подход. И думаю ты его не уловил.
Факты давайте. К примеру поняли вы или нет. У меня возникал вопрос с обновлениями десятка сайта расположенных на одном сервере. Не хотелось заменять уже созданные файлы новыми каждый раз при обновлении. Я наашел решение. Сейчас каждый сайт работает если созданы две директории и один конфикграционный файл. Вопроса с обновлением просто не возникает потому что все сайты работают с одними файлами. В то же самое время решен вопрос с заменой части функционала на отдельном сайте. Это решается копированием нужных нам файлов в директорию сайта. У меня у одного возникали такие пробемы? Или у каждого всего по одному сайту?
mpak Железные нервы, круто написал, я свой нормальный сайт еше не написал) Просто попроси найти ошибки)
mpak Самое первое, что бросается в глаза - процедурное программирование. Современных портальных систем без какой-то объектной архитектры не найти - разве что те, которые начали писаться давно, т.к. никому не охота их переписывать. Второе - html местами вперемешку с php. Я раз дизайн phpbb переделывал кардинально, спасибо, больше низачто за такое не возьмусь. Система, может, и работает хорошо, но к сожалению она безперспективна: за развитие её на добровольной основе вряд ли кто возьмется (никаких интересных инноваций), а на коммерческой не выдержит конкуренции.
Ожидал этого вопроса. У процедурного есть приемущества. Он быстрее работает. Я видел сайты которые написаны на ООП и открываются по 6 секунд. Мой работает за тысячные секунды. В моем случае процедурный подход более выгоден. ООП при одном функционале всегда отсатет от процедурного по быстродействию. Но никто не мешает писать на ООП модули. По поводу кода. Он остался в модулях которые писал с самого начала. В механизме реализованы шаблоны. С коммерческими не собираюсь тягаться. Я писал ее для себя. Как я понимаю работу. То что я могу счас в ней реализовать мне в 95% достаточно. Поддерживать прежде всего я буду на добровольной основе. Но это все к коду не относится. Мы сейчас код обсуждаем.
С процедурным всетаки не убедили. Я считаю в данном случае процедурный подход более выигрышный. Или кто то не согласен? Всетаки хочу показать плюсы своего подхода. Каждый сайт сконфигурирован с двумя директориями. Первая это всегда дефалтная портальная система. Та которую вы видите. вторая это пусышка. В ней только конфиг. Все два или три десятка сайтов смотрят на index.php в дефалтной системе. А он уже в зависимости от сайта каждый раз смотрит есть ли для этого сайта изменения отличные от дефалтной если есть выполняет их. Если нет то выполняет дефалтную. Таким образом система одна а в каждом сайте только конфиг и изменения. Изменяя один файл в дефолтной директории вы меняете код для всех трех десятков сайтов. Причем если в папку отдельного сайта в корень положить index.php дефалтный индекс увидит его и запустит его перестав выполнение сам. Это для того чтобы была возможность использовать модифицированные движки для отдельных сайтов.
полное отсутствие проверок того, что присылает пользователь. Отсутствие внятных сообщений об ошибках. Форма не сохраняет введеных мной данных (регистрация, вход по логину и паролю). + смотря по коду: нет никакого шаблонизатора. Давай вместе накодим шаблонизатор с вложенными циклами а?
Если бы это было правдой никогда бы не возник вопрос о том как соединить ООП и быстродействие http://compression.ru/forum/messages/1100.htm. Это первая ссылка попавшаяся мне по ввденному запросу "Быстродействие ООП" в поисковик.
ну как сказать. Глядя на вот эту твою систему, видно, что проблема быстродействия стоит там не на первом месте. Она вообще не пригодна для реальных сайтов (вспомним отсутствие проверок и внятных сообщений об ошибках). Так что: Давай вместе накодим шаблонизатор с вложенными циклами а?
Говорите конкретикой. Что сколько где? А то беседа сказывается в какую то философию. Жду подтверждения этих слов. Чем мой сайт вам не реальный? Могу еще с десяток привести нереальных которые работают даже очень реально. Вообще при создании быстродействие стояло у меня на первом месте. Если что то не так и можно сделать быстрее покажи где. Да и вообще покажи что нибудь быстрее. У каждого сайта ограничение по памяти стоит 8МБ. При такой настройке большенство систем отказывается устанавливаться.
Давай. Механизм шаблонов есть и он очень прост и понятен. Умещается все в несколько строк. if (mpopendir("modules/$k/$v.tpl")){# Проверяем модуль на файл шаблона $debug = mpct("modules/$k/$v.php", array('modpath'=>$k)); ob_start(); if (mpopendir("themes/{$conf['settings']['theme']}/modules/$v.tpl")){ # Проверяем диреторию тем на файл шаблона include(mpopendir("themes/{$conf['settings']['theme']}/modules/$v.tpl")); }else{ include(mpopendir("modules/$k/$v.tpl")); } $content .= ob_get_contents(); ob_end_clean(); }else{ $content .= mpct("modules/$k/$v.php", array('modpath'=>$k)); } И даже его я бы подсократил на пару строк.
http://mpak.su/users:reg ввожу никнейм "blog" (без кавычек). Жму "Зарегистрировать". Появляется опять эта форма без каких-либо сообщений об ошибках. Пустая. Иду на этот вот http://demo.mpak.su/admin , ввожу demo demo. Жму фото. Жму добавить. Что-то добавляется. Без каких-либо проверок. (пустая запись) Это нормально?
А почему нет. Пустая запись тоже может пригодится. Это действие которым ты добавляешь запись в базу данных. ПОтом всегда можно эту запись изменить или отредактировать. Но адрес ее не изменится. Могу даже придумать ситуацию когда это может пригодится. Ты знаешь что у тебя будет 8 картинок нет не описания ни картинок. Ты вставляешь пустые записи. Устанавливаешь ссылки куда надо и все. работа выполнена. Останется толькодождаться когда принесут картинки и поставить их в свои места. Ну и описание добавить. Ситуация из пальца высасана но тем не менее. Она возможна. Если ты нажимаешь на кнопку добавить при пустой форме то значит хочешь добавить пустую форму. В чем собстно проблема? Проверками только усложняешь систему и уменьшаешь гибкость при ее использовании. Почему бы при создании пустого файла не проверять системе на то что в нем записано и если он пустой герерировать ошибку? Мелкомягкий подход. Меня бесит в винде когда я не могу создать в системе файл с точкой в начале. ПРимер когда программисты считают себя умнее тех кто на их продукте работает. В любой другой системы если ты хочешь создать файл .htaccess даже не возмутится. Винда же слюнями вся изойдет. Так и не даст создать такой файл приходится его через задница создавать.
Этот вопрос возникает только у школьников и студентов. Кроме того: Во-первых, конкретно эта первая ссылка не работает. Во-вторых, за большие возможности при прочих равных ты платишь ресурсоемкостью (память, скорость). Поэтому при равной функциональности процедурный и ООП подходы дают равную скорость. Хоть застрелись. Другой вопрос, что сложные системы написанные процедурно ты застрелишься расширять и поддерживать. Поэтому процедурные системы ограничены в функциональности сверху. А в мелких системах ООП заставит тебя заложить ненужные (в системах такого уровня) возможности. Поэтому ООП системы ограничены в функциональности снизу. Но чтобы это знать, нужно не только нерабочими ссылками кидаться. Верно?