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. Если этот параметр не зададут, то у вас отобразится верстка по умолчанию. А вот класс меню мне не понятен пока.
lol_vova: Как я понял. Чтобы у вас сработал класс, вам надо в url передать параметр option, а для вызова конкретной страницы, нужно передать параметр page. То есть у вас получится что-то типа ?page=blog&option=blogclass. Тогда у вас подгрузятся страница blog.php из папки modules и blogclass.php из папки classes. Остальное пока мне не понятно.
lol_vova: Про контент в бд я имел ввиду только именно содержимое. Вот представьте себе текст и в нем есть выделения курсивом, жирным, подчеркивания, плюс форматирование через css. Вот такой текст хранить в бд -- обычная практика. Обычно из админки такой контент может забиваться через визуальный редактор типа fckeditor, tinymce и т.д.
На практике получается, что вы сначала верстаете, что вам надо. Это простые html страницы с точным дизайном. А потом разносите верстку по файлам. Контент же, обычно вводится через административную часть. Грубо говоря, для каждой страницы у вас должна быть формочка, куда вы будете копировать содержимое (уже сверстанное) и эта форма будет сохранять содержимое в базу. Как я понял, вас именно эта часть пугает. Потому что у вас нет админки. Если ее нет, то единственный способ записать контент -- вручную добавить в базу.
lol_vova: Погодите. Вот там во фронт-контроллере (index) у вас есть код определения класса пхп (файла). Таким образом у вас на любую страницу можно создать пхп файл и класс внутри, унаследовать его от абстрактного класса, переопределить все необходимые блоки (хидер, футер, боди) и выводить все, что душе угодно, как я понял. В реальных проектах. Весь код верстки хранится в спец. файлах-шаблонах. Часть контента, да, может храниться в базе данных. В этом ничего страшного нет.
Александр Козак: Странно. У меня есть предположение, что текст у вас заезжает за видимую область картинки. Попробуйте координаты на середину картинки выставить. А вообще для теста попробуйте создать копию скрипта и бросить его в корень. Туда же бросьте и шрифт. Тогда путь будет просто "arial.ttf".
Как все грамотно делается подсказать не могу. Но вот так сходу, я не вижу тут больших затруднений. Логика вывода простая. Если взять в пример вашу схему базы данных, то формируете запрос на получение, скажем 20 самых новых постов (текст, видео, фото). А далее передаете это во вьюшку и циклом выводите. Для удобства, в запросе можете сделать флажок, показывающий тип поста. При выводе постов смотрите, что у вас сейчас. Если видео, то подгружаете подвьюшку для видео, если фото, то подвьюшку фото и т.д. Далее прикручиваете бесконечный скрол на подгрузку еще 20 предыдущих постов и другие фишки соц. сетей.
grabbee: А что вас смущает? Я запрос не тестил. Грубо говоря, накидал, чтобы в целом было понятно. Может быть я что-то не так понял). Вы точнее объясните, что хотите.
(SELECT text AS post, date FROM table_text WHERE user = authorId ORDER BY date DESC LIMIT 10)
UNION
(SELECT photoFile AS post, date FROM table_photo WHERE user = authorId ORDER BY date DESC LIMIT 10)
UNION
(SELECT videoFile AS post, date FROM table_video WHERE user = authorId ORDER BY dateD ESC LIMIT 10)
ORDER BY date DESC LIMIT 10;
Денис Шелестов: Нет же у вас больших тормозов при запросе. Используйте вариант, предложенный Павлом выше. Сортировка не тяжелая. После сквозной нумерации, по id достанете юзера и будете сразу иметь позицию в curRank.
Дима nahkar: А у вас html-страница, если смотреть вьюсорсом, тоже так вся закодирована? Или во вьюсорсе все нормально отображается? Если это сам сайт кодирует, то придется вручную декодировать. Ниже вам подсказали, как это можно сделать. Если же это у вас при парсинге происходит, то вам нужно поискать место, где стоит кодировка и убрать ее.
Ринат: Странно. Судя по второму скрину, я думал, у вас уже такое где-то реализовано. Там же все как надо выводится?
Логика примерно такая.
Вот вы данные по запросу получили. Теперь в цикле для каждой выводимой строки вы должны проверять поле department.id_dep и сравнивать его текущее значение с предыдущим. Если они равны, то вы все еще находитесь в одном отделе, поэтому ничего для текущей строки в это поле не выводите. Если же текущий отдел не совпадает с предыдущим, тогда вы выводите текущее значение в поле отдела, так как это уже другая группа.
Вообще тут по разному можно. Но это самый банальный вариант.
Можно еще вынести всю логику форматирования вывода в некий класс. А потом во фронтенде простым циклом вывести уже отформатированные значения. Это лучше делать, если у вас еще более замудренная логика форматирования вывода данных. Но под форматирование я имею ввиду не html там, а именно расположение и отображение определенных значений в таблице. Вот как у вас с отделами. Иногда бывает гораздо мудреннее логика. По типу форматирования в excel.
Это надо делать уже не в запросе, а при выводе вьюшки вашей (таблицы). Убирать условием.
В запросе вы так не сделаете. Вернее, это, может, и можно сделать, но все равно выйдет левота. Вы получаете табличку с данными, а как ее дальше форматировать, вы решите при выводе.
heartdevil: Есть еще вариант. Поискал в нете. Можно отвязаться от события и заново привязаться. Но, думаю, что у вас все равно где-то два раза код вставлен или присваивается событие. Попробуйте вынести код в хидер или футер, если можно. Тогда он точно один раз вставится.
By default, most events bubble up from the original event target to the document element. At each element along the way, jQuery calls any matching event handlers that have been attached. A handler can prevent the event from bubbling further up the document tree (and thus prevent handlers on those elements from running) by calling event.stopPropagation(). Any other handlers attached on the current element will run however. To prevent that, call event.stopImmediatePropagation(). (Event handlers bound to an element are called in the same order that they were bound.)
BlastPy: Дайте ссылку на страницу, где выполняется ваш js код. Надо проанализировать html-код.
В общем случае, если вам только к одному элементу нужно навесить обработчик события, то используйте сразу соответствующий метод.
В вашем случае это .click()
.on() метод -- это, для присвоения обработчика группе событий у выбранных элементов.
.preventDefault() - тут не поможет, так как он отменяет только действие по умолчанию у элемента. А какое действие по умолчанию у span?
stopPropagation() - тут тоже не должно помочь, так как оно предотвращает цепочный вызов события сабмит. У вас же не сабмит.