Используйте комбинированный подход. Где-то отдельные таблицы, где-то присоединение описаний из отдельных таблиц. Также можно использовать таблицы с описаниями на разных языках в отдельных полях. И не забывайте, что не обязательно иметь мультиязычность применительно ко всему. Например, у группы может быть описание только на одном родном для всех пользователей группы языке.
Предоставляйте форму загрузки только авторизованным пользователям. В ее обработчике, естественно, тоже должна быть авторизационная проверка. Т.е. полностью защититься от загрузок неавторизованными «пользователями» не получится – это один из видов атак – но от таких попыток со стороны реальных пользователей поможет.
Katerina1993, для основного содержимого статьи допустимо использовать кавычки в незакодированном виде. Если вы будете использовать показанные выше ф-ции, вы рискуете «убить» форматирование текста статьи. Хотя конечно нужно детально разбираться.
Используйте эту выборку только для вывода, а список id в куке меняйте так, как я сказал. И не забудьте убирать дубликаты из этого списка (или по крайней мере не «пихайте» дубликаты в запрос).
Просто используйте значение куки, как очередь. (Добавление)
Т.е. добавляйте последнюю просмотренную запись в начало или в конец списка, при необходимости урезая его размер, чтобы не было «неограниченного» роста.
esterio, я других учу думать головой, а не манерам (читай «форматировать исходники»). И форматирование не связано со стоимостью странички. От слова совсем. Если конечно ты не какой-нибудь джун на собеседовании у серьезного дяденьки с промытыми мозгами. Так что не учите меня, чему учить других.
Если у всех стран один и тот же состав программ, то это фильтрация по двум независимым признакам. Скоро напишу статью. Но в принципе делается элементарно: при помощи сложного условия со связкой AND между простыми условиями.
Даже если у вас «одностраничное» приложение, лучше использовать разные адреса для получения отдельных вопросов с сервера. На это заточено подавляющее большинство каркасов Web-приложений. В чем именно может быть преимущество такого подхода, я писал на днях тут. (Добавление)
Форум съедает якорь. См. оригинальную ссылку в посте. (Добавление)
Можете запустить консоль разработчика в браузере и посмотреть пример g09.ru /products/item-1 – идентификатор при AJAX-запросе также передается в адресе, а не в POST-параметре, что позволяет мне использовать автоматическую выборку из БД соотв. записи, не тратя время на ручную обработку входного параметра и выборку записи из БД. Кроме того, всю автоматическую работу выполняет один и тот же код для по сути разных действий, причем этот код работает для всего приложения, т.е. повторное использование кода в рамках одного приложения колоссальное, потому что разных конечных действий может быть огромное кол-во! (Добавление)
P.S. Конечно подобное можно сделать и для POST-параметров, но, повторяюсь, для Web-приложений это значительно более редкий случай. Такое обычно делается на уровне отдельного модуля, а не приложения в целом.
В вариантах ответов, у меня хранится информация, какой id следующего вопроса.
А что след. вопрос связан с ответом на предыдущий?
id след. вопроса можно хранить в текущем вопросе. Или вообще не хранить, а, например, использовать сортировку и выбор вопросов по порядковому номеру. Кстати, если вопросы не перемешиваются, можно номер хранить явно прямо в вопросе и даже заменить им id, а если тестов много, сделайте групповой ключ из номера/id теста и номера вопроса.
Ни о каком циклическом вызове тут речи не идет. Каждый вопрос – это отдельная страница по адресу вроде /question/тут_номер_или_id_вопро са – используйте код повторно с соотв. входным параметром.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 129
