Therapyx: Смотрите, если вы вот так просто сделаете SELECT * FROM [User], [Categories] без условия объединения этих таблиц, то у вас в итоге сработает CROSS JOIN. То есть значения будут объединены каждое с каждым. Грубо говоря, умножение записей произойдет. В первой таблице было 3 записи, во втором тоже 3, в итоге будет 3*3 = 9 записей. Поэтому ТОЛЬКО если вам умножение записей необходимо в задаче, вы это можете делать. В остальных же случаях. ВСЕГДА используйте условие объединения таблиц через INNER JOIN (либо LEFT/RIGHT). Вы, конечно, можете и в WHERE все объединить, но тогда вам придется аккуратно сочинить правильное условие. Что гораздо проблематичнее, что показал ваш пример. Гораздо лучше использовать условие объединения таблиц через INNER JOIN, а уж потом в результирующем наборе записей фильтровать по WHERE так, как вам нужно.
Therapyx: Вот смотрите. В таблице Categories у вас есть, к примеру, такое множество {1,2,3,2,4,2,1}. В сессии у вас сейчас пользователь c id = 2. Если вы используете свое условие в WHERE, то получаете только такое множество {2,2,2}. Если я вас правильно понял.
mr_blond97: Нет. Это функции языка php. Я как пример привел. Вам нужно сформировать ответ с таким заголовком на запрос от второго сайта. То есть на той странице, которая у вас должна отдавать json, вы должны сформировать соответствующий заголовок.
hime2: Поставьте себе вопрос, а вам действительно полезнее отказаться от jquery и писать все на чистом javascript? Обычно "чистый" javascript используют только тогда, когда хотят написать такую же библиотеку как jquery)). Или функционал, схожий по мощности. На клиенте должна быть очень мощная клиентская логика (производительность стоит на первом месте), чтобы отказаться использовать jquery. Я сомневаюсь, что вам нужно что-то такое для вашей задачи.
Вот смотрите. Вам сейчас тяжело сделать выбор, потому что вы не декомпозировали задачу и пытаетесь ее всю целиком решить. У вас три проблемы. 1) Как хранить данные. 2)Как обрабатывать клик. 3)Нужно, чтобы работало на сенсорах. Решите сначала первую задачу. Определитесь с тем, как хотите хранить данные. В атрибутах или, просто извлекать из элементов. На самом деле, первый вариант можете делать так, как вам удобно. Никаких проблем выбор способа хранения вам не доставит. Главное! Чтобы вам было удобно. 2) Вы думаете слишком долго над выбором обработки события клика. Да выберите метод jquery click() и используйте его. После того как отладите первые две проблемы. Приступите к третьей. Теперь вам надо, чтоб jquery click как-то работал и на сенсорных экранах. Начните гуглить. А может ли jquery вообще работать при использовании сенорных экранов. Возможно, вам придется подключить еще какую-то библиотеку, чтобы jquery заработал на сенсорных экранах, либо вам придется отказаться от него и найти библиотеку, которая будет работать. Вот как-то так.
ichernob: А в какой среде вы программируете? Какого типа у вас приложение? Попробуйте вставить весь код файла в котором программируете в ваш вопрос с пометкой EDIT. То что вы показали, мало для анализа.
Таблица Navigation -- это как бы условная таблица. У вас это может быть что-то другое. Грубо говоря, это таблица структуры разделов (Главная, Новости, Статьи и т.д.)
Таблица FieldType -- это просто справочник типов полей.
Таблица FieldGroup -- это группировка полей и завязка на таблицу Navigation. Вы создатите тут группу и привяжите к любой страницы из таблицы Navigation. Замысел такой, но не факт что получится))
Таблица FieldsAndGroups -- в этой таблице, вы просто создаете поля с привязкой к типу поля и к группе полей.
Иван Украинцев: Ого). Так сразу без пол литра не вкурить).
У вас есть слайдер, а это какая-то библиотека тоже? Если библиотека, то там могут быть колбэки на разные события. На них можно подписываться и писать, что хотите.
Я не очень понял, вы внутри слайдера, когда слайдер активный (то есть произошел клик), запускаете скрипт, который ищет слайд и запускает его отрисовку через vivus.js? Про id тоже не очень понял. Кто принимает только id?
daMage: Я вас понял. Вы правильно сделали, что задумались о таком ограничении. Но на самом деле, эти проблемы, решаются сами собой обычно. Когда пишется валидация. Пользователю просто не дают делать то, что будет потенциально опасно при передаче данных. По аяксу, просто личный опыт. Не говорю, что вы должны полагаться на мое мнение, просто я считаю, что аякс нужен только если клиент об этом говорит, либо по другому уже никак без аякса. У меня бывали случали, когда аякс запрос подвисал. В этом случае, нужно продумывать реакцию на данную проблему, и подстраиваться под аякс. Это касается и других, частей, которые могут зависеть от аякса. А сабмит, он и в Африке сабмит). Даже если что-то пошло не так, это, на мой взгляд, более натуральное явление, скажем так, для пользователя.
Иван Украинцев: У вас какая-то новая задача? Опишите, что хотите сделать, я посоветую решение, если смогу. В целом же запуск скриптов обычно проходит как реакция на событие. К примеру, клик по ссылке, наведение курсора на ссылку, нажатие кнопки и т.д. Если у вас события никакого нет, то чтобы скрипт постоянно выполнялся, вам надо использовать setInterval или setTimeout по обстоятельству. То есть при помощи этих функций вы зададите периодичность выполнения вашего скрипта (js-функция), к примеру, раз в секунду.
daMage: Так вы про файл говорили, я вам по файлу и ответил). Может я вас не так понял. Я думал, вы спрашиваете, как возвращать данные в форму при, скажем, неудавшейся валидации, или, если у вас нужно хранить состояние формы между шагами заполнения формы (пошаговая), или еще как. Вопрос валидации -- это другой вопрос. Есть определенный критерий того, что вы хотите валидировать, а что разрешать. Выше Алексей предложил вам хороший вариант с аяксом. Но, я бы еще раз подумал, есть ли в аяксе необходимость. Ведь простой сабмит страницы и валидация на сервере, думается, более надежное средство. Не буду спорить, просто мое мнение.
Я думаю, вам просто не надо заморачиваться с принципом пискель-в-пиксель. Тогда все у вас будет нормально. Адаптируйте бутстрап так, чтобы у вас на нем получалось верстать основную массу сайтов (забыв о идеальном пикселе). Клиенту важен отлично работающий сайт. Отклонение даже в 10 пикселей он не заметит, если все в конечном счете будет работать отлично. Да и само понятие пиксель в пиксель ввели разработчики, а не клиенты, тем самым усложнив себе жизнь, ИМХО.
heartdevil: Я понял в чем проблема. Вернее проблема в нескольких местах была. У вас по умолчанию показываютс все изотопы. То есть это ВСЕ в меню. Когда вы нажимаете на Портфолио, у вас должно отобразиться только портфолио. Делается аякс запрос, который вам возвращает портфолио и просто добавляет к контейнеру изотопов. Так как там стоит метод append. Если вы хотите все это аяксом делать, то вам надо не append делать, а заного записывать полученные данные из аякс. Либо, если изотопов не так много, то можете их все сразу подгрузить и распределить между фильтрами.
lol_vova: Охо. Погодите. А вот class menu -- это вы реализовали? Или было так? Просто его состоятельность нивелируется просто не передачей параметра option. А это большой минус. То есть вы просто вместо option=menu передадите что-то другое, к примеру, option=news и все у вас развалится. Если это так реализовано в проходящем курсе, то архитектура заведомо неправильная. Меню надо реализовать отдельно в файле (просто код вывода меню из базы без каких-либо наследований от abstract класса) и подключить include-ом в index.php. 2) Создаете файл blog.php. В нем создаете класс blog и наследуете от абстрактного класса. Этот файл помещаете в папку classes. Так как в абстрактном классе имеется абстрактный метод get_content(), то его вы можете переопределить в классе blog. Если вам нужно еще переопределить header и footer, тогда нужно в абстрактном классе поставить у них атрибуты доступа как abstract, то есть так же как и в get_content. После этого в url для страницы blog параметр option будет равен blog. То есть состояние верстки по умолчанию у вас подменится на абстракцию blog. Если этот параметр не зададут, то у вас отобразится верстка по умолчанию. А вот класс меню мне не понятен пока.
