Эм,ЧТО?В джумале ты делаешь 2 шаблона в папке templates,а уже в админке,ты указываешь на какие страницы какой шаблон ставить,проще не бывает,это первое..Насчет того что легко ставить верcтку,бредятина полнейшая :) Ставил кастомизированную тему bootstrap 3 и понял,что хуже просто и не придумаешь,самое убогое это как данные в так называемой вьюхе выводятся,так что я не знаю,о чем вы.
Насчет процедурного подхода это конечно прямо в точку..и поработав всего неделю с битриксом больше всего встречался именно с массивом $arResult.А вот 5 пункт вообще спорный,на разнообразных бесплатных CMS есть разные типовые решение,собственно CMS и предполагает быстрое реализация чего либо.
Ришат Кадыров:Вы работали с "самую коммерчески успешную систему в России"?И что мешает вам показать портфолио своих проектов,где все тоже самое реализовано?Собственно это уже работа менеджеров-проектов разговаривать с клиентами,тем более вбольшинстве случаев заказчики не особо компетентны в этом вопросе,и их не волнует способы реализаций.
..их волнует картинка.И я не знаю,что лошадка будет выбирать,но выбор в изучение API или вместо интуитивного понятных методов и классов ,с точке зрение программиста,помойму очевидна. Кастомизация проектов под CMS,очень трудоемкая,и по мне так не стоит того,ИМХО опять же.
zugo: собственно,получилось связать,правда выглядит не красиво так как,приходится делать два запроса к двум таблицам,вместо одного запроса с джоином к двум таблицам.И собственно вопрос,$data=Input::all()- этой строчкой в контроллере мы сохраняем в переменную все введенные данные,вызывая People::addPost($data) -все там же в контроллере,где в качестве аргумента и есть наши данные,вопрос,почему те данные которые мы передаем аргументом,я не могу вызвать в самой модели?например вот так:
Class People extends Eloquent{
.....код выше....
public static function addPost($data){
return $data;
}
}
Ничего не возращает,просто если мы напрямую к этой переменной не может обратится,не очень понятно,как делать query bulder(запросы) к самой бд..
zugo: Насчет таблиц он понимает что имел ввиду,говоря про таблицу peoples,ошибка то не в этом.Ну хорошо мы их связали,People::all()->with('information')->get(); где этот самый запрос указывать?оО
Ну здесь вы в ручную данные вводите,а у меня они должны приходить с формы.То есть по сути мы сначала в контроллере считываем данные с формы - $data = Input::all(),получая ассоциативный массив.Потом уже в самой модели создаем записи $add = People::create($data),перед этим естественное вызывая в контроллере саму статическую функцию модели с параметром $data соответственно,и вот здесь загвоздка,ведь выдает ошибку,что такого столбца не существует,ну это естественно,ведь он у нас хранится в другой таблице,этот столбец.
Естественно так не срабатывает.Цель,при смене пункта меню,менялись выводимые подгружаемые данные. Пример:
Выбираем пункт меню "Москва" - > подгружаются данные "О Москве"
(этакий фильтр данных "на лету")
А как потом градацию условий настроить?Просто ведь если будет к примеру одинаковые фамилия а имя разные(что нам не нужно),а на выходе при таком запросе я так понимаю,он все равно один списком все что нашел по всем столбцам отобразит..
Армянское Радио: вы как то сами себе противоречите,с начало "А чтобы защититься от SQL-инъекции, вы не должны никогда никакой запрос строить путем конкатенации.",а теперь про метки :)ну ладно
"А чтобы защититься от SQL-инъекции, вы не должны никогда никакой запрос строить путем конкатенации."То есть по вашему мнению если этот запрос будет строиться по принципу конкатенации,который вы предложили,не будет никакой защиты от SQL-инъекции?Тогда если какой нибудь другой способ оО
Армянское Радио: PDO есть,но сюда то смысл скидывать?это он вряд ли сделает ведь перед этим будет валидация данных,а prepare как раз подготовит наш SQL запрос,наличие меток ведь необязательна.Но вопрос то не в этом стоял,а в том как организовать и разделить те данные которые ввел пользователь.
Rsa97: Не ну естественно там будет соответствующая валидация .Насчет разбивание не знаю,щас конечно прямо такой необходимости нету,просто в будущем будут прибавляться поля ...например данные о пользователе(город,дата рождение и .т.д) и ведь надо будет как то распределять,не в одной же таблице все.Или как вы считаете?
Rsa97: Спасибо!но..а если авторизация не предусмотрена ? есть просто форма с полями(имя,фамилия,отчество и отзыв сам),и надо как то раскидать данные по таблицам.
А почему вы поставили индекс на имени "peoples_id_idx",для чего это?вроде же можно было просто ADD INDEX "peoples_id" сделать.
И самый главный вопрос,при добавление отзыва получается мне надо соед. с двумя таблицами?как мне этот внешний ключ переносить в таблицу "отзывов",пока только идея с хранимыми процедурами.