Какой-то странный разговор идет - разговор ни о чём. О каком-то быстродействии, о том, кому как удобно запросы в базу делать, за сколько времени блог можно сделать... Да ни один блог не посещается несколько тысяч раз в день, чтобы думать о производительности движка этого блога. lexa Былобы очень интересно взглянуть на разработанную вами CMS, желательно с примерами действующих сайтов. ЗЫ. Это очень скользкое утверждение.
lexa Ну не знаю насчет сложности баннерокрутилки - пока что ты единственный, кто поднял вопрос о том, что этот пример неподъемен для новичка. Насчет блога: хм, а ведь ты сам немного лукавишь здесь написать блог с нуля у тебя займет ночь (т.е. те же 8 часов), написать блог, используя готовые библиотеки - час? Либо это библиотеки, специально заточенные под написание блогов (в таком случае пример, мягко говоря, притянут за уши), либо ты сам написал супер-библиотеку, которую я уже хочу посмотреть, ибо она получается лучше всяких фреймворков, либо в твоем блоге будут отсутствовать некоторые вещи, без которых нельзя говорить о полноценном проекте - шаблоны, например. В общем ты выкладывай свой пример (можно видео, можно текстовое howto), а я выложу свой, тогда и будем сравнивать. Пример твой насчет скорости работы eval() - тоже лукавый. Когда я сравнивал работу eval и include, я генерировал один большой блок кода (действительно большой, в этом весь смысл - посмотреть различия в скорости обработки кода), засекал время и подключал/исполнял его один раз. В движке ведь eval тоже вызывается всего один раз! А у тебя eval() вызывается десять тысяч раз в цикле - по сути, ты сравниваешь скорости работы eval(echo) и echo. Разумеется, простой echo будет работать быстрее, это же не вызов функции. Ну и последнее: если у тебя 10,000 eval()-ов отработали 0.3 секунды, значит, один eval() "съедает" 0.00003 секунды. Небольшая плата, как мне кажется. P.S. (оффтоп) http://psyco.sourceforge.net/ News: 2 May 2007 "The snake machine is down - died of too much PyPy". *снова чешет затылок* :lol:
psyco — да, эквалиент опкод-кеша. Он говорил про Django — фреймворк под Python, — мощнейщая вещь, на самом деле. Исключительно. В сочетании с не самой плохой реализацией ORM при скорости Python, который с оп-кешем, конечно, не быстрее С++, но гораздо быстрее PHP, дает крайне высокую эффективность программиста. На самом деле, PHP действительно проигрывает Python в скорости, и очень значительно. Один из «минусов» связки Python+Django — нераспостраненность и высокий порог сложности вхождения, что имхо, даже скорее плюс.
Горбунов Олег Ммм... вот оно что. Не знаю, насколько это честно - при обсуждении быстродействия фреймворка приводить примеры фреймворков на других языках. Разумеется, можно взять фреймворк на Джаве, поставить JIT и он "обует" по быстродействию и PHP, и Питон. Но здесь форум по PHP, и PHPC тоже написан на PHP так что прошу вас если приводить примеры более эффективных решений, то тоже на PHP.
Вот и я о том же, я же не кричу, что asm все это по скорости переплюнет, и что на асме можно написать CGI приложение. )))
dark-demon, значит лет через шесть будет хорошо . mmaavv, равлекательные блоги то же блоги, но с посещаемостью несколько десятков тысячь в день. Было бы по крайней мере глупо говорить о скорости на примере сайта с посещаемостью восемь человек. Dagdamor, не "супер-пупер", но и не заточен под создание блогов. Просто набор полезных функций, классов и с фиговиной чтобы работать через админку (и создавать админку). Оки, видео выложу. Только нужно определиться что будет иметь блог. Предлагаю: посты, категории (с иерархией), кейворды (tags в ЖЖ; плоские), комментарии, трекбеки, блогролл (список ссылок на друзей; добавление через админку, с ключевыми словами, для генерации макросинтаксиса типа rel="friend")), вид админки и сайта любой (не будем же жизайны рисовать? ), модерацию комментов и текбеков от спама делать не будем. С eval`ем, наверное, ты прав. Если вызывать его единожды и обрабатывать в нём всё сразу, то получится быстрее. Горбунов Олег, Django, TurboGears и CakePHP (они похожи, ИМХО, потому что все косят под Руби на Рельсах) я упомянул для сравнения скорости работы на них, а не языков на которых они написаны. Исключение только упоминание eval() в версии Питона.
lexa Окей, жду видео и готовую систему. Половина блогских терминов, которые ты использовал, мне неизвестны, поэтому мне нужно либо более подробное описание, либо пример аналогичной системы. - что значит "категории с иерархией"? - что такое "плоские кейворды"? - что за "tags в ЖЖ"? - что такое "трекбеки", "блогролл" (желательно поподробнее)? - и самое главное, ты действительно намерен все это сделать за "час-два"? В общем, напиши все как можно более подробно, чтобы в результате не оказалось, что ты написал одно, а я - совсем другое. Помни, что перед тобой человек, который блоги, мягко говоря, недолюбливает и не слишком хорошо разбирается в них.
Dagdamor, WordPress очень популярный блоговый движок. Категории и кейворды (aka tags (тэга/таги)) это таксономия и фолксономия. Первый тип имеет иерархию подобно директориям в файловой системе: - Папка -- Подпапка -- Подпапка - Папка - Папка -- Подпапка -- Подпапка --- Подподпапка Категория (имхо) у контента может быть только одна. Если за блог взять магазин, а за пост отдел, то название отдела это категория. Второй тип (фолксономия) - кейворды. Они имеют "плоский" вид, как файлы: - Файл - Файл - Файл - Файл Кейвордов у контента может быть множество. Трекбеки это самое сложное для обьяснения (а как ты понял, обьясняю я хренова). Предположим, есть два блога: Блог А и Блог Б. Автор Блога А пишет у себя какую-то заметку. Автор Блога Б хочет её откомментировать, но одновременно написать и себе в блог. Благодаря системе трекбеков автор Блога Б поступает так: пишет себе в блог заметку-комментарий, там же где он добавляет сообщение в поле для трекбеков он суёт УРЛ поста на который собираеться ответить. В итоге он добавляет себе пост, а в комменты Блога А к тому посту, который захотел откомментировать автор Блога Б, добавляется комментарий в виде заметки с Блога Б. Реализуется всё простым POST-запросом через сокеты. Блогролл это ссылки на друзей. Ну да, за два часа это максимум. Просто я писал себе помощника с целью упростить создание нудностей (таблиц, связей таблиц и контента, добавление контента, редактирование контента, удаление контента, работу с аяксом, проверка форм и т.д.), расширить возможности при вёрстке, упростить создание админ-части сайта (всем ведь по-разному нравится) и т.д. В общем: поднять КПД при создании сайта (этим займётся фреймворк) и усложнить хобби себе (я не программист). И у меня получается. Ладно. Давай забьём на это маленькое соревнование. Покажи мне, пожалуйста, как на твоём фреймворке делать контент со связями. К примеру магазинное: таблица юзерей и таблица товаров. Как их связать и выбрать. Кажется, эта связь называется one-to-many. Вот как тут, на сайте на PHPC. Рубрики это категории и они имеют связь с самим обьявлением.
lexa Понятия связей между таблицами как такового в PHPC нет. Там вообще нет ORM - все данные, которые ты выбираешь из таблиц, остаются в виде массивов и не конвертируются в объекты. Если связанные записи нужно просто вывести (например, на странице отображается категория магазина со списком товаров) - то ты используешь переданный странице id категории и делаешь сам два запроса (категория и товары), т.е. связь здесь выступает в роли неявной, учитываешь ее ты сам. От использования явных связей я отказался - обычно количество кода, необходимого для конфигурирования этих связей и доведения их до ума, превышает количество кода для их учета в системе, да и быстродействие страдает. Знаешь, мне хочется взглянуть на твою систему, чтобы понять, как можно взвести хотя бы полноценное управление деревом категорий в админке за час. Там ведь должно быть: отображение дерева, добавление/правка/удаление элементов, перенос элементов. Кроме управления категориями в админке, есть еще статьи и комментарии, а также все вкусности что ты перечислил, а также весь фронт-енд. Еще раз: это система на PHP? Если да, выложи хотя бы фрагмент кода, а то слишком уж оптимистично звучат слова твои
Код (Text): Категория (имхо) у контента может быть только одна. к сожалению это не так говорить, что любой контент можно чётко классифицировать по заданной заранее классификации - закрывать на проблемы глаза. таксономия - задание иерархической классификации и соотнечение с ней контента фолксономия - самооранизующаяся классификация контента - каждому контенту присваивается набор характеристик (тэгов), наиболее значимые из которых отображаются впоследствии в виде "облаков".
Dagdamor, вообще, не люблю выпендриваться, потому что некрасиво. Раз ты хочешь посмотреть, значит я выпендривался. Прошу прощения, если это так. Полноценное дерево элементов и манипуляцию с ними можно сделать за пару минут. Она тоже работает на "родительских отношениях". Нельзя сделать только перемещение, но только потому что я считаю это неправильно. ИМХО, ну нельзя определив альбом "родителем", а песни дочерними элементами, переносить их к другому "родителю". Или ты имел в виду что-то другое? На PHP. Мне не очень хотелось бы выкладывать код. Да и отдельный кусок ни о чём не скажет, кроме как о том, что я больше люблю отдельные функции, чем классы. dark-demon, но классификация определённая заранее может в дальнейшем расширяться. Категории в блогах добавляют, категории в форумах тоже. Сложно представить такой контент, который нельзя чётко классифицировать. (если не брать в расчёт посты готичных девочек в дневниках на ли.ру )
lexa, пример из жизни: на одном форуме есть раздел "религия" и есть раздел "юмор", собрался один чел создать ветку "юмор о религии", но отовсюду его гонят. из религии - потому, что "раздел не предназначен для высмеивания, но для обсуждений", из юмора - потому, что "эта ветка будет интересна прежде всего тем, кому интересна тема религии". другой пример из жизни: выкладывая в сеть несколько композиций я неверно указал исполнителя (тэги были неправильные прописаны). в случае с таксономией - мне бы пришлось именно "переносить" к другому исполнителю. но меня спасла фолксономия - я отредактировал описание и облако тэгов обновилось само.
lexa счет уже идет на минуты... я хочу это видеть! Двухминутный ролик много места не займет. Дело же не в отношениях - я говорю об управлении: формы создания/редактирования, удаление (каскадное между прочим), отображение дерева, желательно в красивом виде. Мне хочется видеть, как выглядит процесс создания и как это выглядит в результате. Правда хочется, как минимум это поможет мне улучшить свой движок, как максимум - ты поможешь всем участникам здесь своим примером. И дело не в выпендреже, а в обмене опытом. Ну ты собственно сам ответил - Самое распространенное изменение в каталоге - это выделение новой тематики или подветки каталога и перенос части записей в него, а также перенос в него схожих тематик. Например, у тебя была категория "Кошки", а потом ты заинтересовался и собаками тоже, создал категорию "Домашние животные", внутри нее добавил "Собаки" и перенес туда "Кошек". EDIT: dark-demon меня опередил...
dark-demon, юмор о религии - прежде всего юмор. Кстати, вот хороший пример почему чёткая классификация важна. Кто-то хочет создать тему "юмор о религии", без чёткой классификации он запихнёт её куда попало, а так задумается: нужна ли такая тема вообще (есть ведь и такие кто за упоминание этих двух слов подряд может придать анафеме). Если вопрос ставится иначе, а именно как ты написал "эта ветка будет интересна прежде всего тем, кому интересна тема религии", то просто классификация идёт в ином порядке. Типа так: - Религия -- Буддизм -- Иудаизм -- Христианство -- Мусульманство -- Юмор - Тачки -- Автомобили -- Мотоциклы -- Скутеры -- Велосипеды -- Юмор Или админы/модераторы сами не очень понимают чего хотят. К тому же, всегда есть "Флуд" . Касательно музыкального файла. Я не очень понял суть примера . Исполнитель был бы категорией, если бы была таксономия? Но, разве, поменяв исполнителю имя категория бы не поменялась? Dagdamor, ну, если какой-нибудь простой блог можно сделать за час-два, то понятно, что отдельный элемент управления делается не три часа . Ты прав, а я очень сильно ступил говоря о переносе элементов. Всё равно, такая функция предусмотрена и исправляется отсутствие смены "родителя" простым добавлением нового поля в форму. Дерево легко обображать через чекбоксы или селект, иерархия обозначается минусами, как я привёл в этом посте или в том где показывал про категории: - Папамама -- Дети --- Внуки ---- Правнуки Удаление, конечно, каскадное. Странно, если было бы иначе . Оки, сделаю удобое управлеие УРЛами и потом забацую видое и выложу. Но, так как я первый попросил, то сначала видео с тебя .
Код (Text): Типа так: - Религия -- Буддизм -- Иудаизм -- Христианство -- Мусульманство -- Юмор - Тачки -- Автомобили -- Мотоциклы -- Скутеры -- Велосипеды -- Юмор угу, и в каждом разделе по подразделу "юмор" а также по разделу "куплю", "продам", "давайте встретимся" и прочие так и получается, когда пытаешься запихнуть перпендикулярные понятия в одно дерево. что, если человек просто хочет посмеяться? предложешь ему бегать по всем разделам? да-да, костыли были, есть и будут... я не исполнителю имя поменял, а композицию перенёс к другому исполнителю. запихнёт в оба раздела и все будут счастливы...
dark-demon, "Или админы/модераторы сами не очень понимают чего хотят" . Это очень плохой пример классификации, который показывает, что при правильном проблемы не возникнит: юмор это юмор, религия - религия, а тачки это тачки. - Религия -- Буддизм -- Иудаизм -- Христианство -- Мусульманство - Тачки -- Автомобили -- Мотоциклы -- Скутеры -- Велосипеды - Юмор По-моему, это правильная классификация на форуме. Есть ещё топики, которые можно создавать в любой из тем по мере надобности. Как не странно, но в теории куда больше проблем, чем можно встретить на практике. По крайней мере, на форумах. Мы, на самом деле, в лес ушли. Ты говорил, что контент нельзя чётко классифицировать при таксономии. Я же говорю что можно. Но ведь никто не запрещает иметь совокупность классификаций, как таксономию, так и фолксономию. Одно другому не мешает, а наобарот помогает.
Написал небольшой туториал по работе со сложными/сложно оформленными формами в PHPC. Все это касается фронт-енда, у админки свой собственный API для работы с формами/таблицами/списками/прочим. Если кому интересно, почитайте.
почему ты то используешь css, то устаревшие аттрибуты? да и зачем эти вложенные таблицы? реально ли прикрутить динамическую генерацию форм (например, добавление однотипных полей)?
dark-demon Я противник бездумного вынесения всего-всего в стили - в CSS должен находиться стиль оформления, а верстка должна оставаться в атрибутах HTML. В стили я стараюсь выносить то, что можно легко исправить (шрифты, например) и при этом не разъедется верстка. Создавать один элемент стиля для одного тега, который больше нигде не используется - это то же самое, что создавать отдельную функцию для одной операции, которая больше нигде не встречается, другими словами, излишняя абстракция. Конечно - это будет выглядеть примерно так: Код (Text): <logic:iterator property=fields item="field"> <insert:formInput title=field:title name=field:name value=field:value/> </logic:iterator> На экране появляется, например, список дополнительных полей профайла участника.
я говорил про динамику на стороне клиента... ясно почему у тебя "логика форм сама по себе требует солидного количества HTML-тегов" всякие border="0" и иже с ним это и есть оформление и оно у тебя прямо в html в виде аттрибутов.
dark-demon Все это тоже можно сделать просто это уже выходит за пределы простого туториала. KISS (WYC)... Твой вариант ничем не лучше - если все вынести в CSS, таблица стилей распухнет во много раз такими вот "одноразовыми" элементами. И что самое неприятное, чтобы внести какие-либо изменения, все равно придется лезть в код самой формы - чтобы посмотреть название элемента, прописанного там, или чтобы посмотреть структуру, понять, что во что вложено и как может называться элемент, не прописанный явно. Зато в стилях нет всякой ерунды, которую "трогать нельзя, иначе все расползется"