Ещё немного о картографии снов
Re: Ещё немного о картографии снов
Как у нас обстоят дела с дизайнерами? Кто-то может сделать дизайн для страниц? Или хотя бы объяснить схему, как это делается?
Пока что у меня прорисовалась такая схема. Есть несколько страниц — домашняя, редактирования профиля, регистрации и т.п., которые управляются PHP-скриптами. PHP-скрипт в зависимости от содержимого сессии, выдаёт контент в формате XML + XSL. В XML содержится динамический контент (например, ник залогиненного пользователя, список JavaScript-файлов, которые нужно подключить, ссылки на связанные страницы и т.п.). К сгенерированному контенту ещё добавляется ссылка на XSL файл, определяющий собственно дизайн. Он зависит от схемы и языка. В XSL-е зашит весь контент в зависимости от смысла страницы, и в нужные места посдтавлена инфа из XML. Чтобы создать тему нужно реализовать эти XSL страницы. В XSL-е можно использовать JavaScript, и можно использовать JavaScript-API сервисных функций. Например, процесс логина делается через AJAX и для этого в движке есть функция user_login, которую нужно вызвать, когда юзер ввёл свои данные для входа.
Если кто-то может оценить этот вариант или предложить что-то получше, было бы здорово. Ну и собственно задизайнить, может есть желающие. Кое-какой функционал уже реализован, но без дизайна это смотреть страшновато.
Пока что у меня прорисовалась такая схема. Есть несколько страниц — домашняя, редактирования профиля, регистрации и т.п., которые управляются PHP-скриптами. PHP-скрипт в зависимости от содержимого сессии, выдаёт контент в формате XML + XSL. В XML содержится динамический контент (например, ник залогиненного пользователя, список JavaScript-файлов, которые нужно подключить, ссылки на связанные страницы и т.п.). К сгенерированному контенту ещё добавляется ссылка на XSL файл, определяющий собственно дизайн. Он зависит от схемы и языка. В XSL-е зашит весь контент в зависимости от смысла страницы, и в нужные места посдтавлена инфа из XML. Чтобы создать тему нужно реализовать эти XSL страницы. В XSL-е можно использовать JavaScript, и можно использовать JavaScript-API сервисных функций. Например, процесс логина делается через AJAX и для этого в движке есть функция user_login, которую нужно вызвать, когда юзер ввёл свои данные для входа.
Если кто-то может оценить этот вариант или предложить что-то получше, было бы здорово. Ну и собственно задизайнить, может есть желающие. Кое-какой функционал уже реализован, но без дизайна это смотреть страшновато.
Re: Ещё немного о картографии снов
Готовый движок WordPress не рассматривали?
Re: Ещё немного о картографии снов
Возник вопрос насчёт поиска снов (по тегам и тексту, и т.п.).
Допустим, юзер хочет найти все сны с заданным тегом и датой в указанном диапазоне. Нода, профильтровав набор снов, выдаст выборку юзеру. Но что делать со снами, в которых дата и/или теги приватные? Ноде они недоступны, поэтому их фильтровать она не может. Максимум, что она может — это выдать все запароленные сны, чтобы уже пойнт их расшифровал и отфильтровал. Это означает повышение трафика и нагрузки на пойнт. Особенно, если снов много. А кроме того, это означает дублирование функционала поиска и на ноде, и на пойнте (что, в принципе, терпимо).
Это касается не только поиска, но и прочих функций, затрагивающих более одного сна. Например, простой просмотр списка своих последних снов, или в хронологическом порядке, подразумевает, что все приватные сны загружены в пойнта. По моим прикидкам на один сон будет приходиться около 2 КБ данных (не считая картинок). То есть, это порядка 1 МБ на 500 снов. В общем-то немного. Их можно будет кэшировать в локальном хранилище, чтобы снизить расход трафика. Кстати, это «забесплатно» будет означать возможность работать в оффлайне.
По сути, это означает перенос почти всей логики на пойнт, нода остаётся как сервер синхронизации данных, плюс-минус.
Это слегка меняет архитектуру ПО, поэтому если кто-то может на этот счёт что-то сказать, то говорите.
Допустим, юзер хочет найти все сны с заданным тегом и датой в указанном диапазоне. Нода, профильтровав набор снов, выдаст выборку юзеру. Но что делать со снами, в которых дата и/или теги приватные? Ноде они недоступны, поэтому их фильтровать она не может. Максимум, что она может — это выдать все запароленные сны, чтобы уже пойнт их расшифровал и отфильтровал. Это означает повышение трафика и нагрузки на пойнт. Особенно, если снов много. А кроме того, это означает дублирование функционала поиска и на ноде, и на пойнте (что, в принципе, терпимо).
Это касается не только поиска, но и прочих функций, затрагивающих более одного сна. Например, простой просмотр списка своих последних снов, или в хронологическом порядке, подразумевает, что все приватные сны загружены в пойнта. По моим прикидкам на один сон будет приходиться около 2 КБ данных (не считая картинок). То есть, это порядка 1 МБ на 500 снов. В общем-то немного. Их можно будет кэшировать в локальном хранилище, чтобы снизить расход трафика. Кстати, это «забесплатно» будет означать возможность работать в оффлайне.
По сути, это означает перенос почти всей логики на пойнт, нода остаётся как сервер синхронизации данных, плюс-минус.
Это слегка меняет архитектуру ПО, поэтому если кто-то может на этот счёт что-то сказать, то говорите.
Re: Ещё немного о картографии снов
Приветствую.
https://cloud.mail.ru/public/3XpD/4Jh5YNRRP - дамп в формате SQL. Там много вариантов, могу кинуть еще в JSON, XML или CSV.
Я занимаюсь и веб-дизайном, но с XSL никогда не соприкасался. Только традиционные HTML+CSS+JS+PHP+SQL.
https://cloud.mail.ru/public/3XpD/4Jh5YNRRP - дамп в формате SQL. Там много вариантов, могу кинуть еще в JSON, XML или CSV.
Я занимаюсь и веб-дизайном, но с XSL никогда не соприкасался. Только традиционные HTML+CSS+JS+PHP+SQL.
Re: Ещё немного о картографии снов
Джэйс, поговорим пока только про таблицу users.
Avatar — это типа имя файла-картинки имеется ввиду? Если так, то с аватарами не всё так просто. В любом случае, его может не быть, поэтому поле может быть пустым. NOT NULL, случайно, не означает, что поле не может быть пустым? А вообще с аватарками пока непонятно. Можно их пока убрать, а потом добавить, если что?
Timestamp лучше назвать с большей смысловой нагрузкой, например, creation_timestamp. Но это мелочи.
В остальном всё вроде нормально.
XSL, похоже, не понадобится по причинам, приведённым в предыдущем посте. Так как львиная доля данных будет обрабатываться на стороне клиента, то особо не вижу смысла заморачиваться с XML/XSLT.
Джэйс (или кто-то ещё), нет ли у тебя энтузиазма взяться сделать несколько PHP-функций для работы с таблицей users? Нужны конкретно вот такие функции:
Можно хотя бы некоторые.
Avatar — это типа имя файла-картинки имеется ввиду? Если так, то с аватарами не всё так просто. В любом случае, его может не быть, поэтому поле может быть пустым. NOT NULL, случайно, не означает, что поле не может быть пустым? А вообще с аватарками пока непонятно. Можно их пока убрать, а потом добавить, если что?
Timestamp лучше назвать с большей смысловой нагрузкой, например, creation_timestamp. Но это мелочи.
В остальном всё вроде нормально.
XSL, похоже, не понадобится по причинам, приведённым в предыдущем посте. Так как львиная доля данных будет обрабатываться на стороне клиента, то особо не вижу смысла заморачиваться с XML/XSLT.
Джэйс (или кто-то ещё), нет ли у тебя энтузиазма взяться сделать несколько PHP-функций для работы с таблицей users? Нужны конкретно вот такие функции:
Код: Выделить всё
/**
* Check if user exists
*
* @param string $user_id user id to check
*
* @return bool True if user exists, False otherwise
*/
function user_exists($user_id)
/**
* Add new user with given fields
*
* @throws Exception On invalid or taken username or email
*
* @param string $username Desired username
* @param string $pass_hash Serialized password hash
* @param string $salt Serialized salt
* @param string|null (optional) Recovery e-mail, defaults to NULL
*
* @return string|null Id of created user or NULL if user with
* given username exists.
*/
function add_user($username, $pass_hash, $salt, $email = NULL)
function update_user_info($user_id, $info)
function get_user_by_username($username)
function get_user_info($user_id)
function remove_user($user_id)
Re: Ещё немного о картографии снов
И... что? Пусть себе будет пустым. В скрипте это буквально две строчки кода, чтобы вместо пустоты подставить какую-нибудь стандартную аву (не в таблицу, а при формировании страницы).
SQL настраивается очень легко, менять можно что угодно и когда угодно.
Я не против взяться.
Но сначала надо обсудить документацию. Если буду работать не я один, то кому-либо еще понимать программную структуру проекта будет проблематично.
Общение клиента и сервера/ноды пока предполагаю в формате JSON, как весьма удобном.
Re: Ещё немного о картографии снов
Пока схема такая.
С точки зрения пользователя пространство состоит из нескольких HTML-страниц. Каждая страница (вход, редактирование профиля, добавление сна, поиск снов и т.п.) представляет собой интерфейс и использует JavaScript-API для выполнения содержательных вещей (проверка логина/пароля на вход, регистрация, редактирование сна и т.п.). Такое разделение сделано для того, чтобы можно было менять внешний вид на готовом функционале. По сути, HTML-страницы — это тема, внешний вид. А JS-библиотека с API делает всё остальное.
Сама JS-библиотека общается с сервером через более или менее RESTful API (HTTP). Там либо plain text, либо JSON. API реализован на PHP, а HTML страницы статичны. Это, например, позволит сохранить их просто на домашний компьютер и работать с локальной базой снов даже без интернета.
Сзади PHP подразумевается MySql. Так как я с ним мало знаком, то пока что дамплю json в файл, это как раз те функции, что я тебе перечислил (в них я локализовал работу с БД). Пока что реализован только функционал регистрации и редактирования профиля. На подходе добавление и просмотр снов. После чего я нацеплю какой-никакой дизайн и выложу.
Если ты к тому моменту сделаешь работу с БД по юзерам в PHP, то подключим твой модуль. Если нет, то сам буду разбираться когда закончу с вышеперечисленным.
Итого подразумевается (пока) три API:
— JS API для интерфейсных HTML-страниц
— RESTful API сервера
— API модуля работы с БД
Все эти API частично уже имеются и будут пополняться. Документации к ним пока кот наплакал (по третьему API это ровно то, что в моём предыдущем посте). Так что документацию ещё предстоит делать.
Если ты возьмёшься что-то кодить, то предлагаю тебе взяться именно за связку PHP-MySql. А остальной код можешь просто посмотреть опытным глазом, потому что у меня нет опыта, и я наверняка наворотил там чёрте что. Так что мнение профессионала более чем ценно.
Если нужно прояснить какие-то моменты — спрашивай.
С точки зрения пользователя пространство состоит из нескольких HTML-страниц. Каждая страница (вход, редактирование профиля, добавление сна, поиск снов и т.п.) представляет собой интерфейс и использует JavaScript-API для выполнения содержательных вещей (проверка логина/пароля на вход, регистрация, редактирование сна и т.п.). Такое разделение сделано для того, чтобы можно было менять внешний вид на готовом функционале. По сути, HTML-страницы — это тема, внешний вид. А JS-библиотека с API делает всё остальное.
Сама JS-библиотека общается с сервером через более или менее RESTful API (HTTP). Там либо plain text, либо JSON. API реализован на PHP, а HTML страницы статичны. Это, например, позволит сохранить их просто на домашний компьютер и работать с локальной базой снов даже без интернета.
Сзади PHP подразумевается MySql. Так как я с ним мало знаком, то пока что дамплю json в файл, это как раз те функции, что я тебе перечислил (в них я локализовал работу с БД). Пока что реализован только функционал регистрации и редактирования профиля. На подходе добавление и просмотр снов. После чего я нацеплю какой-никакой дизайн и выложу.
Если ты к тому моменту сделаешь работу с БД по юзерам в PHP, то подключим твой модуль. Если нет, то сам буду разбираться когда закончу с вышеперечисленным.
Итого подразумевается (пока) три API:
— JS API для интерфейсных HTML-страниц
— RESTful API сервера
— API модуля работы с БД
Все эти API частично уже имеются и будут пополняться. Документации к ним пока кот наплакал (по третьему API это ровно то, что в моём предыдущем посте). Так что документацию ещё предстоит делать.
Если ты возьмёшься что-то кодить, то предлагаю тебе взяться именно за связку PHP-MySql. А остальной код можешь просто посмотреть опытным глазом, потому что у меня нет опыта, и я наверняка наворотил там чёрте что. Так что мнение профессионала более чем ценно.
Если нужно прояснить какие-то моменты — спрашивай.
Re: Ещё немного о картографии снов
Каким образом генерировать уникальный id юзера? Я думаю хэшировать текущую метку времени UNIX.
Re: Ещё немного о картографии снов
Каким образом скрипту сообщать о технических проблемах? Предлагаю JSON.
Re: Ещё немного о картографии снов
Еще уточнение. get_user_by_username() возвращает id юзера?
get_user_info() в каком формате возвращает данные? Ассоциативный массив? Объект? JSON? И тот же вопрос формата переменной относительно аргумента $info функции update_user_info().
get_user_info() в каком формате возвращает данные? Ассоциативный массив? Объект? JSON? И тот же вопрос формата переменной относительно аргумента $info функции update_user_info().
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 111 гостей