- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Язык php5 + база(неважно какая)
Нужно спросить совета, как лучше сделать.
В личку.
Прошу, клоунов с темой "я написал тут одну, чем могу помоч" или "ничего не понтятно, что ты написал поясни" не беспокоить.
При сохранении объекта (например, сохраняем новую статью(таблица article), форма есть, ее постим. как мне передать наименование таблицы или как мне передовать primary key(в посте тянуть эти параметры не очень хочется ) ?
Можно использовать внешние таблицы(с описанием, что например в этой форме есть обновляемая таблица - article , у нее первичный ключ - art_id, и вот такие колонки обязательны для заполнения ), то получается процесс разработки увеличится(нужно прописывать параметры для каждого объекта) .
Третий вариант, где я буду для каждого объекта писать свой скрипт(например, при посте статьи, я вызываю функция doArtSave), но тоже не очень приятно, так как быстро не получится. и мне придеться в каждом скрипте прописывать обязательность полей и т.д.(я не деляю это в джаваскрипте, все происходит на аяхе в PHP)
Может есть на форуме люди , кто уже писал CMS во множестве раз
(я перечислил свои выкладки, может есть способ еще какой новый или улучшение моих)
У самого за плечами не одна CMS, сейчас заканчиваю новую, вот и решил спросить.
Резюмирую пока три
1. передача параметров прям в форме
<form>
<input type="hidden" name="_data[table]" value="article" />
<input type="hidden" name="_data[key]" value="art_id" />
.....
</form>
основной минус - раскрытые схемы бд
2. передача через внешние таблицы, где все описывается
table column_define(
form_name ....
column_key ...
table_name ...
);
минус - нужно заполнять их при новом объекте
3. создание скриптов
function doSave(){
.....
}
пока остановился на третьем.
Третий вариант самый гибкий, но минус, его, что пользователю (администратору) придется выучить основы PHP.
Спасибо на мозгоштурм (если канешно он будет ) )
Только третий вариант + проверка на корректность вводимых данных и отсутствие SQL-инъекций.
Только третий вариант + проверка на корректность вводимых данных и отсутствие SQL-инъекций.
у меня третий то и есть вариант + немного описаний, чтоб более удобно и быстро создавать новые.
Почитайте http://ru.wikipedia.org/wiki/Model-view-controller
Почитайте http://ru.wikipedia.org/wiki/Model-view-controller
У меня на нем и так все ) первые версии уже старался писать так.
Вопрос не в том как постороить ) я же написал. а в том какие есть идеи передачи параметров.
причем здесь модель построения то ?
Судя по топику вы все усложняете.
1 нужно принять для себя как будут формироваться таблицы в бд. Primary - id в любой таблице, например.
2 написать класс работы с базой, который бы отслеживал соединение, иньекции, постил, проверял наличие полей, и тд.
3 Наследуем класс например Article << DBClass
И в Article->uniq("name")
Article->presents("name", "text")
И основной класс также генерит ошибки и выдает при не верном заполнении
те. уже наследуемый.
Можно пойти еще дальше
Например обробатывать связи между таблицами
Article->has_one("author")
И при обращении Article->records("author") -> запись юзера который добавил статью
Таким образом, вам надо только раз прописать какие поля есть обязательные, а дальше работа упрощается.
Судя по топику вы все усложняете.
1 нужно принять для себя как будут формироваться таблицы в бд. Primary - id в любой таблице, например.
2 написать класс работы с базой, который бы отслеживал соединение, иньекции, постил, проверял наличие полей, и тд.
3 Наследуем класс например Article << DBClass
И в Article->uniq("name")
Article->presents("name", "text")
И основной клас также генерит ошибки и выдает при не верном заполнении
Можно пойти еще дальше
Например обробатывать связи между таблицами
Article->has_one("author")
И при обращении Article->records("author") -> запись юзера который добавил статью
1. на каждый новый объект писать класс ?
2. тогда помимо просто человека который прочтя документацию просто протыкает галками, что нужно заполнять и что не нужно, мне нужен программист ООП )
3. "написать класс работы с базой, который бы отслеживал соединение, иньекции, постил, проверял наличие полей, и тд." - это вы кому ))))
а про это "иньекции" - пожалуйста к второкурсникам. у меня бинды еще с первых версий.
Ясно, я не понял сначала :) вы пишите чтобы все из админки контролить.
Тогда успехов.
Есть SugarCRM - кажется так. В ней есть возможность из админки генерировать свои модули, с новыми таблицами, поиском по таблице и много чего еще.
Можете глянуть как у них сделано. Проект открытый.
Есть-то оно есть (в sugarcrm), да только сделано так, что лучше на это не смотреть :) Впрочем, работать - работает.
А по поводу самого топика - то да, mvc в руки и вперед. А при создании из админки нового модуля генерировать php-код (как вариант, необходимый конфиг - не очень понял задачу, к сожалению), который будет подключаться в model.
Есть-то оно есть (в sugarcrm), да только сделано так, что лучше на это не смотреть :) Впрочем, работать - работает.
А по поводу самого топика - то да, mvc в руки и вперед. А при создании из админки нового модуля генерировать php-код (как вариант, необходимый конфиг - не очень понял задачу, к сожалению), который будет подключаться в model.
Я уже посмотрел . мнение одно - тяжолое го...но(да простит меня модератор, за реч грубую)
у меня страница генерится за 7 тысячную секунды(уже с шаблонами и со всеми запросами).
А тут тяжеловато.
Пхп не хочется генерить на лету. не красиво просто получается - роботокод ( не люблю.
Тогда конфиг во внешнюю таблицу, я вижу один выход, если делать юзерфрендли. А что мешает сделать модульность? Иснстал сделать простым и не мучаться с таблицами, потому, что 1 таблицу сделать можно, а если несколько, да еще many-to-many. Задача тогда получается... легче написать код чем из админки генерить :)