как создовать движки для сайтов???

Не, второе издание не читал, а первое - стоит на полке. Во втором, вроде они описывают разработку на ООП.
а у меня первое в электронном варианте .pdf :( не скинешь исходники кода которые в диске шли а то так не разберусь очень нужно
 
Ну во-первых однозначно лучше писать самостоятельно. И если у человека есть такое желание, то не отбивайте его. Но вопрос элементарен. Пишешь модуль обработки статей (смотреть, добавлять, редактировать), по такому же принципу модуль новостей и другие информационные блоки. Загруз центр - на основе листинга заданной директории, систему статистики посещений, и т.д. Потом выделяешь админский интерфейс, закрываешь авторизацией и в принципе минимум готов.
 
Вопрос не так элементарен, как на первый взгляд кажется.
Начнем с того, что нужно на бумажке оформить структуру сайта. Затем, снова на бумажке оформить структуру таблиц базы и разметить связи между ними.
После этого, уже можно начинать гемор с админкой. Пользовательскую часть можно сделать потом.
 
недавно тоже задавался этим вопросом и искал инфу в гугле, нашел несколько толковых советов, но щас уже не найду эти форума... хорошо, что записал всё в тетрадку, терь перепечатываю сюда:

Вначале нужно разработать функциональную ЦМС - что он должен уметь делать:
1) Работать с клиентами ЦМС сайта (администраторами сайта, редакторами страниц, зарегистрированными пользователями сайта и т.п.)
2) Авторизовывать клиентов по логину и паролю
3) Работать со структурой сайта типа дерева (отображать, редактировать, сохранять)
4) Работать с шаблонами страниц (отображать, редактировать, сохранять)
5) Работать с контентом страниц в соответствии с шаблонами (отображать, редактировать, сохранять)
6) Иметь возможность для безопасной загрузки файлов на сервер и привязки их к страницам
7) Вести статистику
и т. д.

Далее разработать структуру БД.
После этого писать скрипты, которые всё это делают, а также генерят страницы сайта в соответствии с информацией, которая хранится в БД.
---------------------------------------
Начинать с определения ролей пользователей, которые тебе нужны в системе: админ, преподаватели, студенты, гости и т.д.
Для каждой роли определяй, что пользователь с этой ролью должен "мочь", делать. Списком возможностей будет приблизительным списком меню для этой роли.
Потом рисуй базу данных. Именно рисуй. На листике. То что получилось на листике переноси в БД.
Потом начинай писать классы для ролей, начиная с самой сложной (у которой больше всего функций).
 
Такими темпами Nulled скоро напишет свою CMS :D
Кстати, в PRO, наверное, можно замутиться :)
 
Вопрос не так элементарен, как на первый взгляд кажется.
Начнем с того, что нужно на бумажке оформить структуру сайта. Затем, снова на бумажке оформить структуру таблиц базы и разметить связи между ними.
После этого, уже можно начинать гемор с админкой. Пользовательскую часть можно сделать потом.
Такой подход верен если Вы пишите CMS с нуля, под заказчика и у вас нет наработок.
Если же плясать не от закзчика а от CMS. идиалогия на мой взгяд не верна.
Я бы сделал так - модульность в первую очередь, хотябы в самом примитивном виде. что даст? нет неоходимости заранее продумывать все про все.
И плясалбы от паблик части. всеже для новичка так наглядей будет.
 
Я бы посоветовал для начала подучить маны/пописать чегонибудь попроще, потом поискать подработку наподобие "исправить/доделать/переделать" тото и тото в двиге таком то, тебе придётся разбираться в различных cms-ках, а когда уже заметиш закономерности и поймёш структуру, тогда сам ответиш на свой вопрос.
 
Я бы сделал так - модульность в первую очередь, хотябы в самом примитивном виде. что даст? нет неоходимости заранее продумывать все про все.
И плясалбы от паблик части. всеже для новичка так наглядей будет.

А давайте поговорим о модульности и о ядре CMS
о взаимодействие модулей и ядра кто как это представляет

вообще я любитель все писать на ООП
но это дает достаточно сложное ядро в целом для понимания других разработчиков

и даже для себя )
я вот гдето почти 2 года ни чего не писал на PHP
сейчас по роду занятия опять к этому возвращаюсь
и чесно сказать сейчас разбирая то что я там понаписал 2-3 года назад... а написано все только на ООП ))
да еще практически без документирования :(

p.s.
На мой взгляд, если ставить цель написать какойто популярный движок, процедурный подход более приемлем
т к разработка дополнительных модулей становиться более прозрачным и понятным для других, в том числе и теми кто не знает вообще ООП либо знает по минимуму.

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

Разговор в топике и велся про то, как начать писать с нуля. До меня не доходит, как можно писать паблик часть, если нечего выводить с одной стороны, и не определен формат вывода контекста. Конечно, если редактировать контекст визуальным редактором и выводить все скопом с тегами - то большой сложности нет, но это не вполне удобно, по крайней мере мне так кажется.
 
Разговор в топике и велся про то, как начать писать с нуля. До меня не доходит, как можно писать паблик часть, если нечего выводить с одной стороны, и не определен формат вывода контекста. Конечно, если редактировать контекст визуальным редактором и выводить все скопом с тегами - то большой сложности нет, но это не вполне удобно, по крайней мере мне так кажется.
Имелось виду:
1. Таблицу набиваем данными - например теми же навостями
2. Делаем вывод в паблик часть
3. Пририсовываем админку.
Почему именно так? потому как с нуля и писать собрался не опытный кодер. Согласитесь что написать вывод гораздо легче чем - запись, редактирование (те функции админки) ? Так получаеться что идем от простого к сложному

Добавлено через 23 минуты
А давайте поговорим о модульности и о ядре CMS
о взаимодействие модулей и ядра кто как это представляет

кхе... ну вот только собрасля сесть поработать :)
а топик вышел на новый интресный поворот :)
Ну ладно к делу, то бишь описанию...
В моем понимании это должно выглядеть так:
Ядро отвечает за подключение шаблонизатора, и собственно самих модулей, модули деляться на статичные и динамичные, статисные подключены всегда, динамичные по мере необходимости (экономим ресурсы, нахрена? но это уже в привычке со времен доса :)

примерно так
PHP:
$smarty = new Smarty();
......

include "menu.php";//подключили модуль меню, он 
//статичный так как меню у нас всегда присутствует
include $_GET["modul"].".php";// подключаем нужный в 
//текущий момент модуль к примеру при 
//index.php?modul=gallery.php подключиться модуль 
//отвечающий за галерею
.........

$smarty->display('index.tpl'); //
 
Назад
Сверху