Решил заняться разработкой GPL phpMyContent

Добрый день!

Вот решил заняться разработкой программы phpMyContent.
Программа предназначена для быстрого создания кабинетов для пользователей из которых можно быстро и удобно управлять данными в базе данных.
Программа будет в виде смеси phpMyAdmin и phpMyEdit (большее сходство phpMyEdit т. к. профиль почти такой же)

Программировать буду только функциями (процедурный стиль без использования фреймворков и шаблонизаторов и т. п.)
Дизай минималистический (что-то вроде phpMyAdmin)

Если есть у кого идеи/предложения и советы по поводу реализации программы буду рад выслушать

Цитата ("worldHell2010"):

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

Управление данными - классная задача.
Вспомните про то, сколько типов данных в MySQL.
Также напомните себе, что есть BLOB, TEXT, ENUM. Вероятно вы не будете повторять phpMyAdmin и придумаете какой-то удобный способ управления данными такого типа.
Не забудьте про InnoDB. Для phpMyAdmin есть плагин, позволяющий более-менее удобно "рисовать" связи между табличками. А что будет у вас ?

Цитата ("worldHell2010"):

Программировать буду только функциями (процедурный стиль без использования фреймворков и шаблонизаторов и т. п.)

Смесь html, php и sql запросов при тщательном рассмотрении заставляет нас задуматься, а все ли мы делаем правильно )
Задумайтесь, почитайте про MVC.
Процедурный стиль, очевидно, подошел бы для функций, где операции выполняются друг за дружкой.
А теперь откройте документацию к MySQL и посмотрите что из себя представляет SQL запрос SELECT, например.
И теперь еще раз подумайте, оправдан ли процедурный подход в вашем случае ?

Цитата ("worldHell2010"):

Если есть у кого идеи/предложения и советы по поводу реализации программы буду рад выслушать

Совет один - сформулируйте для себя задачу более четко.
Вы создаете минималистичный phpMyAdmin для себя ? Видимо нет, раз вы заговорили про GPL и обсуждаете вашу разработку на форуме.
Да и phpMyAdmin мне не трудно развернуть на сервере, 2 минуты занимает.
Отсюда вывод - не стоит делать урезанный вариант другой разработки или повторять чужую разработку. Сделайте что-то новое.

P.S. Вот кстати - сделайте нормальную работу с триггерами и встроенными процедурами. Такой себе WYSIWIG редактор слева на странице и набор сниппетов справа.
P.P.S. Не поленитесь и сделайте нормальную работу с BLOBами, в которых храняться файлы. Если в BLOB поле рисунок или файл какой - я хотел бы его сразу и увидеть и скачать. Сделайте - у вас сразу добавится поклонников )
P.P.P.S. Сделайте чертов универсальный поиск строк по базе. Вот представьте ситуацию - я просматриваю с помощью вашей программы базу, где размещено 200 таблиц (например это база какого-нибудь Joomla сайта). И я наверняка знаю, что какая-то нужная строка текста в этой базе есть, и мне эту строку текста нужно заменить на другую. Но вот беда - я понятия не имею в какой она таблице и в каком столбце и в какой строке. Мне ее нужно найти. Вот и сделайте мне <input type='text' ..>, в которое я вобью эту искомую строку, а ваша программа мне найдет ее в базе.
P.P.P.P.S. Чтобы сделать сводную таблицу, больших мозгов в Microsoft Excel и Microsoft Access не требуется. А в phpMyAdmin мне понадобиться писать LEFT/RIGHT/INNER/OUTER JOIN ON, как-то делать GROUP BY и т.д. Превратите эту мою каждодневную рутину в простой удобный функционал, понятный простому народу.

Цитата:

Вы создаете минималистичный phpMyAdmin для себя ? Видимо нет, раз вы заговорили про GPL и обсуждаете вашу разработку на форуме.
Да и phpMyAdmin мне не трудно развернуть на сервере, 2 минуты занимает.
Отсюда вывод - не стоит делать урезанный вариант другой разработки или повторять чужую разработку. Сделайте что-то новое.

Я писал "Дизай минималистический (что-то вроде phpMyAdmin)". Минимализм относится только к дизайну, а не функционалу
Да, развернуть можно за 2 минуты... Но! phpMyAdmin как видно даже из названия предназначен для админов, а я хочу phpMyContent предназначенный для контент менеджеров.
Привиду пример:
Я создаю парсера и очень часто парсера работают отдельно от CMS т. е. у заказчика нет средств для просмотра/редактирования данных которые собрал парсер... Устанавливать phpMyAdmin - меня вежлево пошлют т. к. с phpMyAdmin работать простой пользователь не сможет... приходится каждый раз создавать велосипед (или использовать чужие скрипты вроде phpMyEdit и дорабатывать под нужны заказчика...)
Также из личного опыта знаю, что бывает часто что редактирование данных через phpMyAdmin не удобно.


Цитата:

Для phpMyAdmin есть плагин, позволяющий более-менее удобно "рисовать" связи между табличками. А что будет у вас ?

А у нас не phpMyAdmin . Задачи проектирования поддерживаться не будут. Для этого можно пользоваться phpMyAdmin


Цитата:

Также напомните себе, что есть BLOB, TEXT, ENUM. Вероятно вы не будете повторять phpMyAdmin и придумаете какой-то удобный способ управления данными такого типа.

- да, хочу реализовать хорошую поддержку для управления полями ввода...


Спасибо за сообщение!

Цитата ("worldHell2010"):

Программировать буду только функциями (процедурный стиль без использования фреймворков и шаблонизаторов и т. п.)

И какие преимущества ожидаете получить от такого подхода?

Цитата ("tvv"):

И какие преимущества ожидаете получить от такого подхода?

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


Например, процитирую это:
Цитата ("classic"):

Процедурный стиль, очевидно, подошел бы для функций, где операции выполняются друг за дружкой.
А теперь откройте документацию к MySQL и посмотрите что из себя представляет SQL запрос SELECT, например.
И теперь еще раз подумайте, оправдан ли процедурный подход в вашем случае ?

А ничего что сам MySQL написан на C (если кто не знает, то С не поддерживает ООП. И только в последние годы MySQL начали переносить на C++ c ООП, но по прежнему как говорят очевидцы - "большая часть MySQL написана на С в процедурном стиле".
И я не понимаю почему Вы применяете процедуры только в линейных алгоритмах (методы классов - это тоже процедуры ).
Да и еще много хорошего написано именно с помощью процедур.
ООП конечно важен. Но в очень ужжж больших и сложных системах. Если учесть, что ООП сможет принести пользу только если использовать хотя бы 4 основных понятий: полиморфизм, наследие, инкапсуляцию и абстракцию... хотябыыыы...
А стиль когда функция заменяется инкапсуляцией в класс и при этом не используются остальные возможности ООП... думаю это не разумно
Думаю дело в том, что Вы ярые сторонники ООП методологии в программировании. А мне пофигу, мне чем проще тем лучше, хоть ООП, хоть процедуры, хоть прототипы.... Каждой проблеме свое решение

Вот я тоже так думал 3 года назад, когда начал писать свою CMS. Только функции и один единственный класс для работы с базой. Все работала замечательно, пока код не увеличился до десятков тысяч строк. Тут уже приоритеты поменялись, количество классов заметно выросло, и получилась смесь ООП и процедурного стиля. Выигрыша получилось три: заметно уменьшилось количество кода, сильно повысилась читабельность, повысилось удобство и скорость дальнейшего развития кода. И вот смотрю я на все это дело с сегодняшней точки зрения и понимаю, что начни я так писать раньше, не потребовалось бы 3 полных рефакторинга и несколько месяцев жизни. И кто знает, может будет и 4й с переходом на mvc. Тут главное сразу понять, что проект может оказаться перспективным и захочется его развивать. А это означает, что процедурного подхода уже не хватит. Даже если не используются все эти 4 понятия из ООП, даже если это не требуется для функционала, надо смотреть на то, как это может повлиять на читабельность, расширяемость и поддержку проекта через 2-5 лет.

Как вы оцениваете свои шансы на успех?
Вы сможете поддерживать код в одиночку?

Цитата ("worldHell2010"):

А ничего что сам MySQL написан на C (если кто не знает, то С не поддерживает ООП. И только в последние годы MySQL начали переносить на C++ c ООП, но по прежнему как говорят очевидцы - "большая часть MySQL написана на С в процедурном стиле".

А ничего, что первая версия MySQL вышла в 1995 году (это значит, он начал писаться гораздо-гораздо раньше), а стандартизация C++ была только в 1998 году?
До этого язык C++ развивался лишь собственными силами автора, то есть С++ не был промышленным стандартом, не существовало эффективных компиляторов, не было переносимости (компиляторы разных производителей под разные платформы работали каждый со своим диалектом C++), и поэтому все крупные компании в те времена использовали за стандарт именно старый добрый проверенный уже парой десятилетий Си.

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

Цитата ("worldHell2010"):

А стиль когда функция заменяется инкапсуляцией в класс и при этом не используются остальные возможности ООП... думаю это не разумно

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

Одна из важнейших целей ООП — как раз сделать код проще для понимания человеком. И инкапсуляция очень в этом помогает.
Надеюсь, Вы знакомы с методиками оценки сложности кода?
Так вот, например, инкапсуляция позволяет значительно уменьшить количество параметров, передаваемых в функции, за счет использования свойств класса. Уже одно это делает код проще, то есть снижается сложность кода, что важно для любых проектов, даже небольших.

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

Вообще тут много можно писать, думаю, Вы всё это знаете. ООП потому и придумали, и приняли за стандарт, чтобы делать код проще, понятнее для разработчиков, и соответственно дешевле.

Цитата ("Lisio"):

Вот я тоже так думал 3 года назад, когда начал писать свою CMS. Только функции и один единственный класс для работы с базой. Все работала замечательно, пока код не увеличился до десятков тысяч строк. Тут уже приоритеты поменялись, количество классов заметно выросло, и получилась смесь ООП и процедурного стиля.

Да, вот именно! Если кода десятки тысяч то тут без ООП тяжело, но я не думаю, что моя программа будет таким гигантом...


Цитата ("tvv"):

А ничего что сам MySQL написан на C (если кто не знает, то С не поддерживает ООП. И только в последние годы MySQL начали переносить на C++ c ООП, но по прежнему как говорят очевидцы - "большая часть MySQL написана на С в процедурном стиле".

А ничего, что первая версия MySQL вышла в 1995 году (это значит, он начал писаться гораздо-гораздо раньше), а стандартизация C++ была только в 1998 году?
До этого язык C++ развивался лишь собственными силами автора, то есть С++ не был промышленным стандартом, не существовало эффективных компиляторов, не было переносимости (компиляторы разных производителей под разные платформы работали каждый со своим диалектом C++), и поэтому все крупные компании в те времена использовали за стандарт именно старый добрый проверенный уже парой десятилетий Си.

Я имел в виду, что ничего страшного нет в работе с MySQL через функции (мов сам MySQL смогли написать с помощью функций...). И то, что в процедурном стиле можно писать не только линейные алгоритмы. А то, что такие вещи как СУБД или ОС нужно проектировать/разрабатывать с применением ООП - с этим я согласен на все 100%


Цитата:

Как вы оцениваете свои шансы на успех?
Вы сможете поддерживать код в одиночку?

Если думал бы, что не смогу, то не делал бы.
Часто приходится делать админки для управления данными в БД, поэтому опыт в этом направлении есть хоть и не гигантский. Думаю получится...

Цитата ("worldHell2010"):

Да, вот именно! Если кода десятки тысяч то тут без ООП тяжело, но я не думаю, что моя программа будет таким гигантом...

Гигантом? Это всего лишь один движок написанный одним человеком за 3 года, причем реального времени на него было затрачено от силы месяцев 6-9. Все остальное время на его основе делались проекты для себя и на заказ. Я бы не стал это называть даже крупной разработкой, не то что гигантом. Думайте заранее во что выльется ваш проект через несколько лет. И думайте реалистичными цифрами.

Цитата ("worldHell2010"):

Я имел в виду, что ничего страшного нет в работе с MySQL через функции (мов сам MySQL смогли написать с помощью функций...). И то, что в процедурном стиле можно писать не только линейные алгоритмы.

Страшного может и нет, но с каждым килобайтом кода хорошего становится все меньше.

Вы пишете на PHP. За счет отказа от классов вы хотите повысить производительность?=)
Если нет - то игра не стоит свеч, любой продукт грубо говоря с количеством строк больше, чем 1-2 тысячи уже напишется быстрее с ООП.
Другое дело, что если вы еще недостаточно опытны в ОПП, то выгода будет незначительна, если будет вообще.
Но обучаться то всегда полезно.

А вот я пришёл в веб из "классического" программирования - десктопы, приложения БД, ... Я люблю ООП, я использовал ООП почти всегда, на моих системах работали целые предприятия... Но в вебе... Здесь мне удобнее использовать по большей части процедурный подход. ООП хороша когда есть какое-то сложное поведение объектов, когда какие-то хитрые взаимосвязи между ними. Например on-line игра, как уж тут без ООП? Сложно.
Но абсолютное большинство проектов, которые я встречал в вебе - простые системы с сотней таблиц в БД. Такие проекты без всякого труда делаются "на процедурах". Тут дело в аккуратности и грамотном проектировании. Неудобоваримый код в виде спагетти можно легко сделать и процедурами, и объектами.

Цитата ("worldHell2010"):

Если есть у кого идеи/предложения и советы по поводу реализации программы буду рад выслушать

Мой совет: не спрашивай советов такого рода. Решил - делай. И наплюй на всё остальное. Решил процедурами - делай процедурами. Решил на ассемблере - делай на нём. А советы лучше спрашивать чисто технические, а не такие общие.
ИМХО конечно.

Цитата ("oren"):

простые системы с сотней таблиц в БД

Зачем в простой системе сотня таблиц?

Цитата ("Lisio"):

Зачем в простой системе сотня таблиц?

Ну если хотите, называйте системы, которым требуется сотня таблиц, сложными.

Цитата ("dervinar"):

За счет отказа от классов вы хотите повысить производительность?=)

Я этого не говорил.

Цитата ("neadekvat"):

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

ООП пробывал давно и не только в PHP.


Вчера вечером сделал некоторые наработки для phpMyContent - http://193.169.87.135/phpMyContent/
Сделал за пару часов, поэтому криво

Пришел к выводу, что в одном место все же прийдется использовать ООП, а именно в движке конструктора интерфейса.
Когда заходите на страницу http://193.169.87.135/phpMyContent/options/table.php, выбираете базу данных, потом таблицу из базы. Внизу появляется таблица с полями и описанием выбранной таблицы из базы данных. При выборе поля внизу экрана сейчас появляется:
"FUNCTIONS:
substr
preg_replace
tag_split
strupper
strlower

HTML FORM ELEMENT (with all attributes):
text
text (input element)
textarea
password
select
check box
radio box
image (+crop, resize)
flash-player (for video)
flash-player (for audio)"

- вместо этого текста будет появляться мастер для настройки отображения поля в редакторе данных. Т. е. все поля можно будет настроить.
Будет выбор HTML элемента с помощью которого отобаржать поле (+ ввод HTML параметров для тега input, если потребуется), выбор функции которую применять для текущего поля перед отображением в редакторе (например отображать первые 50 символов поля, или отображать все в нижнем регистре, или перед отображением удалить все HTML теги ну и т. д.)

Так вот ООП думаю нужно будет применить именно для этого мастера т. к. - это будет "ядро" системы. Также тут будет управление отображением HTML элементов формы, а также работа со всеми видами данных MySQL. Тут будут и перегрузки, и наследование и абстракция... а функциями тут будет действительно тяжелее.