Разное

я (как новичек) залез бы в нужный мне движок, и обязательно проковыряю все до мелочей, каждую строку
открою для себя что то новое
и попытаюсь написать такое же для укрепления знаний

а в двух словах все таки что такое движок CMS ? понятно что двигатель, но...

> В этом случае да, нужно лезть в исходный код, нарушая принцип инкапсуляции.
> Однако, это считается порочным подходом.
Ага, но не в интерпретируемых языках :)
Когда код свободно доступен, частенько появляется желание заглянуть в его кишки.

Хотя ничего страшного в этом не вижу. Если API спроектирован нормально, то, даже просматривая код, трудно без танцев с бубном (runkit, reflection) поломать его нормальную работу.
Однако анализ кода позволит лучше понять как тот же самый фреймворк работает изнутри и выбирать более эффективный метод или класс для конкретной задачи. Или найти причину "почему же эта херня не работает!?!?!?", узнать что проблема во фреймворке, на скорую руку смастерить костыль, отправить багрепорт производителю и получить + в карму :)

В ядро лазят, когда технологии только становятся, когда в 20-х годах прошлого века создавалась наша авиационная техника, моторы вываливались из самолетов прямо на показательных парадах. Тут жить захочешь - полезешь и в двигатель и все остальные части самолета. Сейчас конечно, это нонсенс. В Web, да и вообще в программировании пока приходится лазить в двигатель, хотя подавляющее большинство программистов уже не пишут свою операционную систему для новой машины, не создают компиляторы, базы данных и вообще много чем готовым пользуются. Однако, инструмента для создания универсального сайта пока нет - т.е. поставил на виртуальный хостинг и на кластер одну и ту же систему, нажал пару кнопок - на виртуальном хостинге появился блог с системой администрирования, а на кластере - социальная сеть. Вот такого нет - среда слишком сложная, причем она постоянно меняется, а двигатели вываливаются на головы посетителям, поэтому нужно много много специалистов по двигателям, чтобы их оперативно обратно в самолет засовывать.

>Вы лишь подключаетесь по API и делаете что хотите, а как это все работает Вас не должно волновать.
Конечно. Если я, допустим, программист 1С, то я ж не лезу в исходники 1С. Это как с техникой. Знаю много прекрасных водителей, которые ничего не понимают в устройстве авто. Но водилы классные. И зачем знать-то? Почему иномарки так и ценятся - там дай API в виде руля, педалей и переключателя скоростей, и - погнал. На нашей - нужно быть автомехаником. И часто "лазить в ядро".
...Западные капитаны многие вообще не знаю, как устроен их корабль-то. Это наши каждую гайку знают на своем теплоходе и ходят в промасляных кителях. С одной стороны, оно и хорошо. С другой - ...не знаю. Залез как-то в рубку огромного парома который между Хельсинки и Стокгольмом ходит - пустили, сказал, что флотский сам, посмотреть хочу - спрашиваю капитана, какие у него главные ДВС - сколько цилиндров, сколько лошадок, как запускаются и т.д. Так не знал! Вызвал механика. Причем третьего. Главный механик, вероятно, тоже был не в курсе :)

>ну не скажите) чтобы хорошо знать кмс, нужно всё таки изучить исходники :) не все, но в основном.
А я и не говорил, что они все хорошо написаны... Более того, FrameWork-ом систему не просто так называют, как правило, так называют системы не имеющие собственного языка программирования или не имеющих полного и замкнутого API. В этом случае да, нужно лезть в исходный код, нарушая принцип инкапсуляции. Однако, это считается порочным подходом.

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

ну не скажите) чтобы хорошо знать кмс, нужно всё таки изучить исходники :) не все, но в основном.

Есть язык программирования PHP и есть его реализация. Вы для создания программ на PHP, часто смотрите исходный код PHP на C? Интерфейс (PHP, набор функций, набор методов) вашей CMS в идеале должен быть таким, чтобы разработчикам даже в голову не приходило смотреть как она устроена, все бы у них получалось средствами, которые предоставляет CMS. А уж как это в ядре реализовать - это вопрос реализации ядра: хоть язык новый пишите, хоть API, хоть просто набор разрозненных библиотек.

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

получается мы его подключаем в index.php
и уже непосредственно через файл ядра идут все обработки нужных функций?

видимо я не совсем понимаю различие ядра от программного интерфейса

Тут понимаете какая штука, вы хотите делать ядро, а говорите об интерфейсе программирования. Если говорить, об программном интерфейсе, какие инструменты предоставить внешнему разработчику (в данном случае вы и внешний разработчик и разработчик ядра). В такой ситуации ядро может быть любым и устроено каким угодно образом. А интерфейс нужно проектировать таким образом, чтобы внешний разработчик имел возможность сделать все что угодно, не заглядывая и не вмешиваясь в код ядра. А будет ли это ООП или функции большого значения не имеет (главное чтобы интерфейс был последовательный, а названия функций и классов единообразным).