Ещё немного о картографии снов

[ioneks]

Как у нас обстоят дела с дизайнерами? Кто-то может сделать дизайн для страниц? Или хотя бы объяснить схему, как это делается?

Пока что у меня прорисовалась такая схема. Есть несколько страниц — домашняя, редактирования профиля, регистрации и т.п., которые управляются PHP-скриптами. PHP-скрипт в зависимости от содержимого сессии, выдаёт контент в формате XML + XSL. В XML содержится динамический контент (например, ник залогиненного пользователя, список JavaScript-файлов, которые нужно подключить, ссылки на связанные страницы и т.п.). К сгенерированному контенту ещё добавляется ссылка на XSL файл, определяющий собственно дизайн. Он зависит от схемы и языка. В XSL-е зашит весь контент в зависимости от смысла страницы, и в нужные места посдтавлена инфа из XML. Чтобы создать тему нужно реализовать эти XSL страницы. В XSL-е можно использовать JavaScript, и можно использовать JavaScript-API сервисных функций. Например, процесс логина делается через AJAX и для этого в движке есть функция user_login, которую нужно вызвать, когда юзер ввёл свои данные для входа.

Если кто-то может оценить этот вариант или предложить что-то получше, было бы здорово. Ну и собственно задизайнить, может есть желающие. Кое-какой функционал уже реализован, но без дизайна это смотреть страшновато.

[логопед]

Готовый движок WordPress не рассматривали?

[ioneks]

Возник вопрос насчёт поиска снов (по тегам и тексту, и т.п.).

Допустим, юзер хочет найти все сны с заданным тегом и датой в указанном диапазоне. Нода, профильтровав набор снов, выдаст выборку юзеру. Но что делать со снами, в которых дата и/или теги приватные? Ноде они недоступны, поэтому их фильтровать она не может. Максимум, что она может — это выдать все запароленные сны, чтобы уже пойнт их расшифровал и отфильтровал. Это означает повышение трафика и нагрузки на пойнт. Особенно, если снов много. А кроме того, это означает дублирование функционала поиска и на ноде, и на пойнте (что, в принципе, терпимо).

Это касается не только поиска, но и прочих функций, затрагивающих более одного сна. Например, простой просмотр списка своих последних снов, или в хронологическом порядке, подразумевает, что все приватные сны загружены в пойнта. По моим прикидкам на один сон будет приходиться около 2 КБ данных (не считая картинок). То есть, это порядка 1 МБ на 500 снов. В общем-то немного. Их можно будет кэшировать в локальном хранилище, чтобы снизить расход трафика. Кстати, это «забесплатно» будет означать возможность работать в оффлайне.

По сути, это означает перенос почти всей логики на пойнт, нода остаётся как сервер синхронизации данных, плюс-минус.

Это слегка меняет архитектуру ПО, поэтому если кто-то может на этот счёт что-то сказать, то говорите.

[Jace]

Приветствую.

https://cloud.mail.ru/public/3XpD/4Jh5YNRRP - дамп в формате SQL. Там много вариантов, могу кинуть еще в JSON, XML или CSV.

Я занимаюсь и веб-дизайном, но с XSL никогда не соприкасался. Только традиционные HTML+CSS+JS+PHP+SQL.

[ioneks]

Джэйс, поговорим пока только про таблицу 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)

Можно хотя бы некоторые.

[Jace]

его может не быть, поэтому поле может быть пустым

И... что? Пусть себе будет пустым. В скрипте это буквально две строчки кода, чтобы вместо пустоты подставить какую-нибудь стандартную аву (не в таблицу, а при формировании страницы).

SQL настраивается очень легко, менять можно что угодно и когда угодно.

нет ли у тебя энтузиазма взяться сделать несколько PHP-функций

Я не против взяться.
Но сначала надо обсудить документацию. Если буду работать не я один, то кому-либо еще понимать программную структуру проекта будет проблематично.

Общение клиента и сервера/ноды пока предполагаю в формате JSON, как весьма удобном.

[ioneks]

Пока схема такая.

С точки зрения пользователя пространство состоит из нескольких 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. А остальной код можешь просто посмотреть опытным глазом, потому что у меня нет опыта, и я наверняка наворотил там чёрте что. Так что мнение профессионала более чем ценно.

Если нужно прояснить какие-то моменты — спрашивай.

[Jace]

Каким образом генерировать уникальный id юзера? Я думаю хэшировать текущую метку времени UNIX.

[Jace]

Каким образом скрипту сообщать о технических проблемах? Предлагаю JSON.

[Jace]

Еще уточнение. get_user_by_username() возвращает id юзера?
get_user_info() в каком формате возвращает данные? Ассоциативный массив? Объект? JSON? И тот же вопрос формата переменной относительно аргумента $info функции update_user_info().