Концепции и сценарии25.06.2011 Ханов О.А., письмо С.О.По поводу "проекта" (как оно есть сейчас). 1. В каталоге "IMG" открывается новый подкаталог, в него сбрасываются фотографии, которые будут добавлены в БД. 2. Готовится текстовый файл с описанием новых фотографий (формат - см. приложение) 3. Запускается программа FOX корректировки базы данных (с индексацией) 4. Запускается программа FOX, которая извлекает информацию из БД и делает HTML на разные темы со ссылками. Команды DIR достаточно, чтобы сделать HTMLы с перелистыванием фотографий, но для ввода текста сейчас надо открывать другой файл. HTML - закрыть, а текст открыть. Причем, прежде чем это сделать, надо запомнить имя файла фото, и затем набрать его в тексте. Все это требует недопустимо большого внимания. Легко забыть и что-нибудь перепутать. Надо сделать так, чтобы можно было написать описание, глядя на фото. И не запоминать имя файла - программа могла бы и сама его прочитать. Все остальное можно пока не менять - клиент делает описание - некто в стороне делает из этого базу и дает клиенту готовый продукт - базу в HTML. Далее надо очень подумать - еще какие функции можно предоставить клиенту. Для глобальной базы по крайней мере индексы должен выдавать центр. Другие возможные функции центра: - нормализация описаний объектов и имен. - определение пересечений по именам, времени и месту, извещение клиента. - цензура текстов и фотографий для формирования "отборной" и "элитной" базы данных, размещение и/или просмотр информации в которой может быть платным. - платная оценка специалистом качества фото или текста (с комментарием). На сегодняшний день имеются базы (в формате dbf) - Список имен (ФИО, даты рождения/кончины, место рождения) - Список фотографий (имя файла, дата съемки, место съемки, номер архива) - Список объектов (Имя, Тип /дом, парк, музей, лес.../, Принадлежность к объекту более высокого иерархического уровня /пр. Большевиков - Петербург, Кингисепп - Ленингралская обл., Петербург - Россия.../) - Список Фото-Имена - Список Фото-Описание - Список тэгов к фотографиям (Слово, Тип, Класс) - Список Фото-Тэги - Список текстов (Название, Автор, Дата создания, Адресат, Персонаж, Соавтор) - Список Тексты-Тэги - Список Тексты-Имена - Список Тексты-Объекты - Список Тексты-Даты - Список Архивов Надо добавить базу "События" и "Увлечения" _____________________________________ Приложение. ФОРМАТ описания фото Каталог/имя файла+Дата+Место ФИО1 ФИО2 ... !!Тэг1 !!Тег2 ... %Краткое описание фото (до 80 символов) пустая строка (Символы "+,!!,%" - маркеры для программы чтения описания и корректировки базы) 27.06.2011. С.О., письлмо Ханову О.А. По поводу базы (пользовательской, не "общей"). Файл описания получается все-таки вторичным. Да, надо оставить существующий механизм из-за его универсальности, но если держать в голове концепт "базовый", он не нужен. По-любому, текущая реализация имеет в наличие развернутую базу данных, которая в данном конкретном случае не используется. И уж в любой момент можно экспортировать данные из базы в текстовый файл. Я свожу концепцию реализации к двум: 1. мы даем флешку (или целый накопитель) с развернутым Денвером и оговариваем принцип создания базы. Типа есть каталог "альбом", там создаешь любые подкаталоги и сливаешь в них фотографии. Дальше напускаешь на это программы с веб-интерфейсом, описываешь фото и оцифровываешь результат.. Где хранятся фотографии - понятно, но как хранится все остальное - знает только разработчик (мы). Но можно сделать экспорт того, что ты описал в какой-то файл , если тебе захочется применить другие программы, алгоритмы и способы хранения данных, Весь контент храниться в "поле зрения" Денвера" и может быть без особых проблем переложен на интернет-сервера с сохранением структуры. Можно задать критерии переноса - рейтинг не ниже такого-то, автор такой-то, только этот альбом и т..п. Это простой способ. 2. все фото хранятся на каких-то носителях пользователя. Мы даем флешку с инструментом, который позволяет: а) описать фотографии (файлы описаний хранятся где-то рядом с изображениями), б) сохранить фотографии и описании для переноса в и-нет. Пункт "а" уже реализован, Но есть большой вопрос с сохранением. Мы дали лишь инструмент, вне компьютера "клиента" нет ничего - ни реальных фото, ни реальных описаний. Нужно озадачиваться копированием контента. Коль скоро он расположен непонятно где, нужна "кнопка" его копирования из конкретного места. Нужны механизмы определения принадлежности контента к определенному автору и уникальности записей внутри самого контента. Нужны алгоритмы, сохраняющие этот контент в общей базе, нечувствительные к перемещению файлов на компьютере пользователя (файлы могут иметь одинаковое имя и дату создания и т..п.) Это сложный способ, Но он хорош тем, что описания в нем изначально являются самостоятельными объектами и не зависят от инструментов их обработки. Поэтому, собственно, начал реализовываться именно этот способ. Я склоняюсь к п.1. И там и тут используется Денвер и по большому счету, вопрос сводится к тому, на диске какого объема он инсталлирован (хватит ли его для всех твоих фото). Сейчас он на 8Гб флешке, но может стоять и на 1 Тб. винчестере. Единственное неудобство в размещении фотографий - предопределенный каталог. Да и ладно! Если Денвер не запускать, то будет обычнейшее хранилище фото. Если запустить - подстыкуется база. В данном случае в плане описания будет проще - появится возможность выбора имен, тегов, альбомов и т.п. из списков, уже хранящихся в базе. Но. Клиент потеряет наглядность описаний (спасет их экспорт в файлы) и "прозрачность" понимания системы в целом. С другой стороны, может это ему и не нужно. Что касается WEB-структуры. Ее можно, естественно, сделать на любой модели. Имея Денвер это не нужно (будут создаваться динамические страницы). При желании можно сделать конвертер базы данных в набор HTML страниц - как у тебя сейчас. Большое "но" всего проекта: Денвер - windows-зависимая система. Если она где-то не пойдет - накрываются оба варианта реализации. 28.06.2011 Ханолв О.А., письмо Ханову С.О. Если я правильно понял, в п.1. абсолютно вся информация - фото, описания, обработчики и т.д. располагаются на флэшке (или в другой, специальной памяти). Можно сделать копию всего этого в И-нете. П.2. отличается от п.1. тем, что фото располагаются не на флэшке, а в другом месте у клиента. На флэшке остаются описания и обработчики. Т.е. основное отличие - надо копировать фото на флэшку или не надо ничего перемещать. Я склняюсь к тому, что перемещение (копирование) фото не только полезно, но и необходимо. Сценарий действий пользователя при подготовке альбома таков. 1. Пользователь нащелкал много фото и скинул все это в некий каталог. Далее можно запустить редактор-денвер. Но прежде, чем... 2. Надо хотя бы немного поработать с изображениями - убрать ненужное, повернуть, увеличить, вырезать, поиграть с экспонированием. Кто-то захочет фотошопить. Результаты обработки лучше сохранить отдельно - либо с другим именем, либо в другом каталоге, либо на другом диске - поскольку мы считаем, что смысл в сохранении оригиналов есть (спустя время может появится желание сделать все по-другому, и если оригиналы не искажены, то это можно). Когда нет у клиента желания этим заниматься - можно предложить услугу. Появляются копии - появляется тема - где эти копии располагаются - на флэшке, на сервере, или где-то еще. Т.е вопрос о размещении становится естественным. ___________________ Я вижу несколько сценариев хранения и просмотра индивидуального альбома. 1. Весь альбом - на флэшке или на винчестере. Больше нигде никакой информации по этой теме нет и никакие другие специальные средства (кроме компьютера) для ввода, просмотра и корректировки не требуются. 2. Альбом размазан по компьютеру. Фото - в компьютере, на дисках, на внешней памяти, на других компьютерах, доступных через локальную сеть. Все управление - на флэшке. 3. Альбом на сервере, просмотр через Интернет. 4. Альбом размазан по Интернету - фото на разных сайтах. Управление - на сервере. Если я не ошибаюсь, ты говоришь о первых двух вариантах. Мне кажется, для всех вариантов будет применение. ___________________ Если иметь ввиду (пока), что общий альбом есть сумма частных (не пересекающихся), то общее на таком сервере только одно - список альбомов (или список авторов). Мне кажется, "механизм определения принадлежности контента определенному автору" здесь не должен быть сложный. В пределах каждого индивидуального альбома можно индексировать, именовать файлы, каталоги и прочее как угодно - без оглядки на другие альбомы. "Уникальность записей внутри контента" получается "сама собой" - полное имя файла изображения (с каталогом) уникально. Если общий альбом есть простая сумма частных, построение такого общего не требует больших усилий. Надо добавить в список новое имя автора, проверить его уникальность и загрузить его информацию в отдельный каталог. Частные индексы сохраняются, к ним просто добавляется номер автора (альбома), после чего индексы становятся общими, но не теряют уникальность. При таком варианте создание интегрированной базы - отдельная, независимая задача, которой можно заняться позже. Мне кажется, "не интегрированная" общая база сама по себе имеет смысл. Т.е. ее надо оставить и после того, когда будет создана другая. ______________ Возможны разные сценарии взаимодействия клиента и сервера ("центра"), попробую что-то перечислить. 1. Клиент засылает на сервер пакет фотографий, видит их в своем альбоме. Поскольку он еще ничего не сказал про эти фото, они все попали в раздел "необработанное", в котором фото отсортированы только по дате поступления. В любое время клиент может что-то сказать про них, и фотографии с вновь введенной информацией переместятся в другие, "осмысленные" разделы. "Держатель" альбома имеет возможность изменять информацию о фото в любом разделе - там, где он его увидит. 2. Клиент получает флешку и исчезает. 3. Клиент получает флешку и возвращается с информацией для базы данных. 4. Клиент скидывет массив необработанных фото. После "физического" или электронного ввзаимодействия получает готовый альбом, а центр получает информацию для базы данных. Физическое взаимодействие с клиентом кажется странным, но я вижу его в случаях: 1. Передаваемый объем - тысячи фото. 2. Клиент не хочет или не может заниматься этим сам, но готов передать фото и надиктовать описания (имена, дата, место; теги можно поставить без него). 3. Клиент интересен для центра, надо его уговорить. ____________ Без интернета я не могу посмотреть новые программы, а живу в основном в оф-лайн. Кстати, если завязаться дла просмотра только на PHP, частного альбома без Интернета не будет. Т.е. не всегда и не везде его можно посмотреть. _________ Посмотрел новую версию. Видимо, не слишком внимательно - не увидел изменений. Режим "Загрузить промежуточную базу" не прошел. 29.06.2011 Ханов О.А., письмл С.О. Написал преобразователь твоего формата в свой, т.е. встроил редактор в существующую систему. Это значит, что уже можно им пользоваться и после обкатки - распространять. Два пожелания (простое и сложное). 1. На сегодняшний день работа с базой идет в FOX, а он не понимает имена файлов более 8 латинских символов. Поэтому просьба сократить discription до (например) discript.txt 2. Очень затрудняет процесс необходимость Интернета, здесь он плох и не всегда доступен. Это принципиально? С флешкой тоже не очень удобно работать. Но, насколько понимаю - можно перейти куда-нибудь - на диск L. В начало |