» Разработка редактора с древовидной структурой

Предлагаю перенести сюда обсуждение разработки редактора с древовидной структурой нового поколения
Также - обсуждение разрабатываемой мной системы многопользовательского аутлайнера, основанного на системах контроля версий, с интеграцией в системы программирования, системы плагинов для этого аутлайнера и других фич.
Близкие темы: Редакторы с древовидной структурой - выбираем лучший

Здесь будет собрано описание как можно большего количества функций подобных редакторов, функции будут разгруппированы по логическим группам. Предлагайте свои функции с описанием области их применения

Не знаю планируете ли вы в чем-то повторять функционал ToDoList'а, но есть одно пожелание, оно скорее для ToDoList'а, но так как он на С++, то может это будет тебе под силу - в любом случае - откоментируй ПЛС сложность такой работы:
1. Есть ToDoList, есть плагин для него - Календарь - ссылка на той же странице где он и сам. Есть написанная на С++ программа CALIZO - живет на sf.net (т.е. также open source как и все вышеперечисленные).
2. Надо сделать viewer (можно и плагин) для файлов .ics (файлов iCalendar) которые экспортируются из ToDoList.
3. Что должно отображаться (в сравнении с тем, что уже делается в Calizo):
- название задачи
- дата начала, дата окончания
- порядок следования задач должен быть аналогичный как в ТДЛ (а не как их оптимизирует кализо)
- каждой задаче должно соответствовать справа бар-диаграмма - timeline (or simple Gantt chart) можно полностью аналогично как у CALIZO
4. Если задача кажется вам решаемой - я напишу еще нюансов и сделаю желаемые скриншоты
5. Что это даст: сейчас нет простой и наглядной программы по отображению файлов ТДЛ в виде диаграмм ганта, (одна требует Явы - GanttProject, другая отображает не в том виде)
Написание такого вьюера дало бы возможность полноценно использовать ТДЛ - как средство управления проектами

Перенесу сюда то, что писал в предыдущей теме с исправлениями.

Требования к программе.

1. Не Web-интерфейс.
2. Должна быть портабельная (работать без установки с флешек).
3. Основные функции должны быть в ядре, а дополнительный добавляться с помощью плагинов.
4. К каждой странице можно прикреплять файлы (в WikidPad можно прикреплять файлы, но все они лежат в куче).
5. Неограниченная вложенность записей.
6. В разных ветках могут быть разные страницы с одинаковыми названиями. Это, кстати, одна из вещей, которые мне не нравится в WikidPad, что не может быть разных страниц с одинаковыми названиями.
7. Есть мысль сделать так, что в качестве хранилища всех страниц использовать не один файл, а папку, в которой каждая страница хранится в отдельном текстовом файле. Вложенность реализуется с помощью подпапок. Как вариант, вместо папки использовать zip-архив.
8. Возможность для плагинов подключать внешние генераторы картинок, как сделано в WikidPad с MikTex и GraphViz.
9. Раскраска кода (в виде плагина).
10. Возможность шифровать отдельные страницы (в виде плагина).
11. На каждой странице используется визуальный редактор.

SFC, в обсуждении в теме "Редакторы с древовидной структурой - выбираем лучший" вроде решили, что все будет на плагинах. Пока я плохо представляю себе, что такое ToDoList и как он работает, но идея добавить к разработке еще и функционал средства управления проектами (а также и багтрекера) - хорошая. Тут все зависит от того, насколько грамотно будет продумана и реализована базовая архитектура системы.

Поэтому в этой теме также предполагается собирать и струткурировать теоретический материал по разным функциям подобного софта.

Jenyayх, в ближайшее время я постараюсь перенести сюда свои идеи с rsdn

И немного о плагинах

Плагины представляют собой dll-ки, которые содержат обработчики событий, посылаемые движком.

Плагины должны иметь возможность:
1. Изменять страницу после ее прочтения (например, расшифровывать зашифрованные страницы)
2. Изменять страницу перед ее записью на диск (например, шифровать)
3. Вставлять на страницы свои элементы, которые затем могут изменяться с помощью этого плагина (например, редактор формул)
4. Возможность вставлять элементы, не видимые на странице (например, метки для страниц, по которым в будущем можно будет осуществлять поиск)
5. Возможность изменять интерфейс окна программы (добавлять кнопки на панель задач, добавлять разные виды для одних и тех же страниц, например, просмотр сырого HTML. Но об этом стоит поговорить отдельно)

Вот примерно третья часть требований к начальному этапу Все вроде просто, но мне очень важно разобраться с файловой организацией, иначе я не смогу сделать то что хочу так что для начала попробую сделать часть 4 - даже без html, на простых текстовых файлах.

Реализация
Проект разбивается на несколько этапов реализации
Разработка ведется на C++

Этап 1 - многопользовательский аутлайнер
Основные требования
1. Многопользовательская система; т.е. одновременно с базой могут работать несколько пользователей с разных компьютеров, объедиеннных в сеть;
в качестве средства реализации для начала предполагатеся использовать систему контроля версий (например Subversion или распределенную VCS); в дальнейшем (на этапе >=4) возможно появление своих протоколов

2. Интерфейс
2.1. В основе организации данных лежит иерархическое дерево. Каждый элемент этого дерева имеет пользовательское имя (произвольное), внутреннее имя (уникальное в пределах текущего уровня текущего узла дерева), и - опционально - вложенное поддерево.
Т.е. почти полная аналогия с файловой системой: внутреннее имя = имя файла/директории, пользовательское имя = содержимое файла, вложенное поддерево = список файлов внутри директории.
2.2. К каждому элементу дерева привязан некоторый файл - "страничка". Файлы могут быть разных типов. На первом этапе используется единственный тип - "html document".
2.4. Для страниц типа "html" предусмотрены команды РАЗМЕТКИ и ФОРМАТИРОВАНИЯ; при этом предусмотрено создание ИМЕНОВАННЫХ СТИЛЕЙ разметки; каждому стилю разметки можно сопоставить определенные настройки форматирования. Предусмотрено создание кнопок быстрой разметки (к каждой кнопке можно привязать свой стиль) и предполагается, что пользователи будут пользоваться именно разметкой, но предумсотрена также и панель непосредственного форматирования.
Список возможностей разметки и форматирования:
* h1, h2, h3, h4, h5
* number list, marked list
* horizontal line
* table
* hyperlink
* attach object
* insert image
* insert external object
* bold, italic, underline
* font, font size
* text color, back text color, paragraph fill color
* text alignment - by left, center, right, width
* pre-formatted text
* table formatting

2.5. Архитектура построена по принципу MDI, т.е. в одном окне можно открыть сразу несколько страниц; предусматривается общая панель закладок, с помощью которых можно переключаться между страницами; Изменения в странице могут сохраняться как автоматически при потере фокуса (как в аутланерах), так и командой Save (как в редакторах);
2.6. Предусматриваются разные способы открытия страницы:
* как в аутлайнерах: загрузка страницы в текущее окно по одинарному щелчку на узле в дереве; загрузка страницы в новое окно по щелчку при удерживаемой клавише (Ctrl).
* как в IDE: загрузка страницы в новое окно по двойному щелчку на узле в дереве;
Предусматривается также откытие страницы во внешнем текстовом редакторе типа notepad; для этого используется контекстое меню узла дерева. Изменения, внсененные во внешнем редакторе, вносятся в отображение текущей страницы автоматически по получении фокуса.

3. Переносимость.
3.1. Система не требует инсталляции, не использует реестр для хранения каких-либо данных; все необходимое для ее функционирования включается в один exe-файл; все пользовательские настройки хранятся в xml-файле, который находится в той же папке что и exe.
3.2. Все плагины хранятся в подпапках папки plugins, расположенной в той же диреткории что и exe; таким образом, каждый плагин имеет собственную папку, в которой размещены все необходимые для него файлы.

4. Файловая организация
4. Файловая организация
4.1. Каждая страничка хранится в виде отдельного файла (html, в дальнейшем - другие форматы);
4.2. Каждый узел дерева хранится в отдельном файле xml; за счет этого появляется возможность открывать части базы как самостоятельные базы.
4.3. Принцип раздельного хранения файлов выбран для обеспечения работы системы контроля версий: скорее всего, разные пользователи будут редактировать разные страницы / узлы дерева; даже если они редактируют одну страницу, в большинстве случаев формат html и xml позволит произвести автоматическое слияние; в случае конфликта формат html и xml лучше всего ориентирован на ручное разрешение конфликтов.
4.4. Нет жесткой привязки базы к файловой системе; тем ни менее, есть настраиваемые стратегии размещения файлов базы в файловой системе базы. Т.е. возможно разместить, например, все файлы базы в одной папке без вложенности, но по умолчанию будет иерархическая стратегия размещения. Это связано с одним из основных назначений системы - интеграции базы знаний с исходниками больших программных проектов, у которых уже есть сформировашаяся стурктура файлов и папок. При создании новой странички пользователь должен иметь возможность выбрать папку размещения этой странички, но должна быть также и стратегия по умочанию (создание странички по умолчанию = одно нажатие клавиши!)

Цитата:

4.1. Каждая страничка хранится в виде отдельного файла (html, в дальнейшем - другие форматы);
4.2. Каждый узел дерева хранится в отдельном файле xml; за счет этого появляется возможность открывать части базы как самостоятельные базы.

А чем узел отличается от страницы? В одном узле может быть несколько страниц?

Еще, наверное, понадобятся дополнительные файлы, которые будут хранить какие-то настройки для каждой страницы. Или их хранить в тексте самой страницы?

Узел - это элемент дерева, запись в xml файле, описывающем часть дерева (в простейшем варианте - путь к странице и имя страницы)
Страница - это файл в котором хранится собственно информация
Одному узлу соответствует одна страница определенного типа

Настройки для страницы... хорошая идея, я почему-то об этом не подумал. А что за настойки?

Цитата:

А что за настойки?

Например, те же метки для страниц. Или настройки, которые показывают надо ли шифровать страницу. Или иконка для страницы в дереве, цвет, которым рисуется страница в дереве. Может быть ссылки на внешние CSS. Если узлы хранятся отдельно от содержимого, то, пожалуй, настройки стоит хранить в узле, но тогда плагины должны уметь изменять эти настройки.

http://www.amlpages.com/Rus/ - Aml Pages. Вот, пожалуйста. Движок уже есть, SDK есть, пишите плагины какие душе угодно. Программа не бесплатная, но 595 рублей, не так уж и дорого, если инструмент действительно нужен.

Цитата:

http://www.amlpages.com/Rus/ - Aml Pages

Еще один аутлайнер Опять все в единой базе, опять rtf
Конечно, встраивание в IE и сохранение страниц в базе - это хорошо (хотя я пользуюсь оперой)... это тоже хорошая идея для будущих плагинописателей.
Изначально (до публикации этой темы) весь проект рассматривался мной как плагин к Visual Studio для интерактивного документирования исходных текстов программ, навигации по этим исходникам и ведения корпопативной базы знаний по проекту. Ничего подобного просто не существует. Все аутлайнеры, за исключением TreePadX MultiUser edition - принципиально однопользовательские, в IDE не встраиваются и хранят все файлы в одной базе.
Сейчас есть экспериментальная IDE, с подсветкой синтаксиса, с редактором на основе CrystalEdit, чтением основных файлов проектов (vcproj, dsp, dsw, sln) и т.д. А после публикации сообщения возникла идея расширить функциональность и добавить функции как минимум многопользовательского аутлайнера, MindMapper'а и сделать все это на системе плагинов - просто потому, что так удобнее, многие функции которые предлагает Jenyay, мне не нужны, и наоборот, а плагины позволят все это реализовать без особых проблем. В любом случае, плагинная архитектура способствует более грамотному программированию.
Теперь предстоит долгая работа по собиранию всех этих кусочков воедино (ибо времени нет вообще), затем публикация какой-то беты, эксперименты с плагинами и т.д.

Кстати, за ссылку на AMI pages спасибо. Там хорошая документация на плагины, и даже примеры исходников есть, будет с кого содрать

xcode
А на чем собственно писать-то кстати? Может на Java? ПортАбельность будет изначально...

GingerFox

Скорее всего C++, а портабельность пока имеется в виду, что можно прогу носить на флешке и работать она должна без установки.

Проект будет состоять (и уже состоит) предположительно из следующих частей:
ядро - чисто алгоритмическая библиотека на С++ (компонуется как static library); ядро по сути кроссплатформенное, т.е. должно собираться под любой ОС любым компилятором;
tinyxml - кроссплатформенная библиотека для работы с xml, компонуется как static library;
GUI оболочка - С++/MFC, так удобнее потому что под MFC больше компонентов на сайтах типа CodeProject; распределение функциональности между ядром и оболочкой будет построено так: все что можно запихнуть в ядро без нарушения принципа кроссплатформенности - запихивается в ядро, остальное в оболочке;
плагины - C++/WinAPI, возможно C++/WTL, в виде динамических библиотек;
компилятор и IDE - Visual Studio 2005
интеграция с IDE (VS2005,2008) - C#, кроме интеграции с Visual Studio 6.0; там - минимальная интеграция на C++/COM (одна панель инструментов)

т.е. на выходе имеем две независимые части: портабельную exe-шку с плагинами и непортабельные интеграции в IDE

Java - не надо, видел я софт на яве, хотя если например кому-то захочется написать интеграцию с Eclipse или другими Java-IDE, то естественно писать будут на яве.

автор Braintank
Общие требования к персональной СУБЗ
* работа со съёмных носителей без установки, с сохранением предпочтений как в реестре, так и в виде дискового файла
* работа с базами до 4 Гбайт
* ввод метаданных для всех ЕХ (также и нетекстовых) и поиск по ним
* индексирование всех текстовых ЕХ и метаданных (описание текстовой информации в терминах машинного языка запросов для упрощения и ускорения поиска)
* сканирование результатов поиска без закрытия диалогового окна с возможностью по результатам изменить критерии
* использование «интеллектуальных схем» для обработки собранной информации (mind mapping, tag cloud)
* морфологический поиск
* фразовый поиск, позволяющий находить ЕХ со сходными фразами (использование механизмов неполного соответствия)
* автоматическое сравнение версий двух раздельно пополнявшихся БЗ с возможностью полуавтоматической синхронизации под управлением пользователя
* корректный, без потерь и изменений, вывод отдельной или подмножества ЕХ, а также нетекстовых элементов ЕХ в основные текстовые, графические и гибридные файловые форматы
* автоматическая идентификация ЕХ в базе при сохранении похожей ЕХ
* ссылки на внешние файлы, как находящиеся на локальном диске, так и на удалённые ресурсы
* импорт в активную базу других баз как целиком, так и в виде отдельных указанных пользователем подмножеств ЕХ
* подключение сторонних средств проверки правописания
* использование всех сложившихся приёмов ускорения и упрощения профессиональной обработки текстов: наращивание выделения по числу щелчков мышью (слово-строка-абзац-гранка), ускорение навигации посредством Ctrl + стрелки, грамотное удаление посредством Ctrl + Del, отображение символов форматирования и операции с ними…
Ввод информации
* перетаскивание из окон других программ и в эти окна
* вставка из буфера обмена (включая накопительное слежение за буфером)
* импорт с локального и удалённого диска документов текстовых, графических и гибридных форматов
* наличие интегрируемого в браузеры инструментария агрегации данных с веб-страниц, их первичной чистки и сведения к единому стилевому формату
Вывод информации
* перетаскивание ЕХ или любого её фрагмента в окна других программ
* экспорт (как отдельных ЕХ, так и всей БЗ / любого её фрагмента) в дисковые файлы самой СУБЗ, в гипертекстовые форматы, в TXT, RTF и т.д.
* экспорт отдельных выбранных нетекстовых объектов в дисковый файл
* печать всех ЕХ или по выбору
Минимально приемлемый набор форматов
* RTF и TXT с автоматическим распознаванием или контрольным просмотром для ручного указания исходного способа кодирования оригинала
* BMP, JPEG, PNG, GIF, WMF, EMF
* HTML и RTF c таблицами, растровыми и векторными графическими элементами
Обработка текстовых данных
* полная поддержка Юникода
* полная поддержка табличного представления данных (преобразование таблиц в текст и текста в таблицы, создание таблиц вручную
* использование всех возможностей гипертекстовой разметки
* использование абзацных и символьных стилей с возможностью изменения части параметров стиля глобально для указанного фрагмента текста
Графические данные
* удобный ввод (как части EX) данных в графических и мультимедийных файловых форматах (перетаскиванием, через буфер обмена и импортом)
* объём БЗ при импорте графики должен увеличиваться на объём добавленного файла + небольшой процент
* графика должна храниться в неизменном виде и сжиматься без потерь, без перекодировки в текст
* введенная в базу графическая и мультимедийная информация должна корректно отображаться (или воспроизводиться посредством внешних программ)
* введенные в базу файлы должны легко, без дополнительных манипуляций извлекаться в прежнем виде

Добавлено:
-------------------------
Для создания благоприятных условий предлагается сформулировать ряд требований к софту.
1. Спецификация стандарта базы.
...Определив стандарт базы мы тем самым существенно снижаем требовательность к софту. Любой софт который поддержит стандарт позволит не потерять однажды вложенные усилия на создание базы. Существенно упрощается написание всяких конвертеров и поддержки другими нестандартными системами. Спецификация базы это основа всей дальнейшей работы.
2. Мелочи уровня конкретного софта как-то функциональность в порядке приоритета.
3. Вариант базы online. Но эта разработка выходит за рамки данного проекта как интернет за рамки обычного телефона.

Для спецификации базы можно предложить следующие элементы.
1. База является совокупностью объектов и хранится одним файлом.
2. Каждый объект имеет метку (идентификатор) и спецификацию (тип, архивный, удалённый, только чтение, шифрация или много чего ещё).
3. В заголовке базы присутствует версия базы и версия программы последний раз базу сохранявшая.
4. Индексный модуль в начале или ещё где удобнее. Дополнительно может сохранятся отдельно.
5. Модуль ссылок (кто чей родитель, кто на кого ссылается) также там где удобнее. Дополнительно может сохранятся отдельно.
------------------------------------------------------------------------
О причинах моего внимания к стандарту базы можно зачитать на форуме

Супер! Практически все и планируется сделать так как здесь расписано Причем, благодаря выбранной архитектуре, многие вещи получаются автоматически

Только вот база однозначно будет храниться НЕ единым файлом, а как раз наоборот - все что можно разбить на кусочки, будет разбито. Обоснование этому я вроде приводил - база изначально задумывается как многопользовательская и многомашинная, для синхронизации будут использоваться системы контроля версий (Subversion или какие-то из распределенных VCS). Городить огороды с собственными протоколами синхронизации в ближайшее время не планируется... тем более что есть замечательное решение - VCS, прекрасно работающие для огромных C++ солюшенов с десятками проектов и тысячами файлов.

В очень далеком будущем есть идея сделать на базе этой архитектуры пиринговую базу знаний по типу MSDN Library, в которую юзеры закладывали бы переведенные в html электронные книги, журналы и обработанные сайты, и обменивались бы ими через протокол типа BitTorrent. Но это - в будущем, не раньше чем будет релиз "Аутлайнер + Плагины + Интеграция в Visual Studio".

Форматы - или xml, или xml-совместимый html. Это обусловлено все той же причиной - системы контроля версий умеют соединять text-based форматы автоматически. Например, если два юзера одновременно правят один файл, и Юзер1 вставил строчку в начало файла, а Юзер2 - в конец, то VCS в общем случае сама сможет слить эти две файла в один.
Рисунки, мультимедиа, естественно, будут в своих обычных форматах... Также в обычных форматах будут всякие pdf, djvu, doc, но без возможности редактирования из базы. Т.е. хочешь отредактировать рисунок - пожалуйста, двойной щелчек на рисунке - и он открывается в любимом графическом редакторе. Можно свободно делать с ним все что угодно, кроме переименования файла. Т.к. база основана на файловой системе, НИКАКИХ заморочек с встраиванием, BLOB'ами и прочими прелестями COM-технологии не будет.

Все что можно оформить в xml, будет оформлено в xml. На втором этапе планируется как минимум сделать "векторный редактор" для подготовки различных диаграмм - UML, MindMaps, блок-схем и т.д. Такие диаграммы прекрасно сохраняются в xml.

Сейчас я изучаю оптимальные варианты размещения файлов на базе файловой системы. Где хранить документы, ноды дерева, аттачи и т.д., пишу код для загрузки дерева и управления этим деревом (добавление, удаление элементов и т.д.)

ЗЫ: долго думал что такое "ЕХ". Полез в оригинальный пост, оказалось - "единица хранения". На самом деле можно назвать проще - "документ"

2 xcode

Цитата:

В очень далеком будущем есть идея сделать на базе этой архитектуры пиринговую базу знаний по типу MSDN Library, в которую юзеры закладывали бы переведенные в html электронные книги, журналы и обработанные сайты, и обменивались бы ими через протокол типа BitTorrent.

Так-так, отсюда поподробнее. У меня есть пара проектов (как идея) которые хочется свести в один. Первый проект представляет собой глобальное хранилище файлов на базе 2p2 технологий.
Основные принципы организации сети Схрон.
Сеть состоит из узлов. Узел предоставляет в качестве ресурса место на своём диске, канал и процессор. В сети присутствуют два типа узлов. Информационные (обрабатывающие) узлы (и-узел) и файловые (раздающие) (ф-узел). Особенностью сети является разбиение выкладываемых файлов на части и хранение этих частей на разных узлах.
Второй проект не привязан к технологии 2p2, но его необходимо привязать для защиты от государств и прочих организация. Как это сделать пока не представляю. Проблематика:
Интернет предоставляет доступ к огромному массиву знаний накопленных людьми. Но вот проблема. Найти нужные знания непросто даже при наличии таких поисковых гигантов как Google. Приходится тратить намало времени на поиск и анализ найденного. Кроме того, существует проблема достоверности найденной с таким трудом информации. Даже если вы нашли что-то нужное нет никакой гарантии что это нужное является реальным решением вашей проблемы. И, таким образом, перед нами актуализируется следующая задача: построение системы предоставляющей легкодоступную, точную и достоверную, структурированную и упорядоченную информацию.
И так далее. С моей точки зрения, оба этих проекта, если их получится реализовать, окажут громадное влияние на социум. Влияние сравнимое с появлением инета. Этот проект делает ненужным любые аутлайнеры. Ну почти Общественная база знаний такого качества меня (и многих) более чем устроит.

Ну, аутлайнеры всегда будут нужны Создать универсальную систему на все случаи жизни все равно не получится.
А про пиринговую сеть... обычная пиринговая сеть, разница только в том, что информация упорядочена посредством xml-структуры глобального дерева. У узлов разного уровня есть модераторы - тоже разного уровня. Формат информации стандартизирован - html. Отсюда - индексирование, контекстный поиск и т.д.

Идея возникла потому, что у меня (да и у многих) есть куча электронных книг в djvu, pdf, doc, chm и т.д. Хоть я их и упорядочиваю по директориям, но все равно это файлы, а хотелось бы единой базы знаний типа MSDN Library.
Соответственно, идея в следующем: разные люди сканируют книжки (или скачивают отсканированные), распознают их, переводят в html, фильтруют, разбивают на иерархические части и добавляют в соответствующий раздел глобального дерева. Одному человеку провести огромную работу с тысячами книг просто не под силу, а комьюнити - справится запросто. Отсюда и идея пирингового обмена.

Короче, это все тот же html аутлайнер, но вместо VCS к нему прикручена P2P. В любом случае, делать такую штуку я сейчас не буду, но если интересно - да, пиринговый интернет имеет будущее, поэтому я закладываю в структуру аутлайнера максимальную гибкость - вдруг пригодится

Цитата:

Интернет предоставляет доступ к огромному массиву знаний накопленных людьми. Но вот проблема. Найти нужные знания непросто даже при наличии таких поисковых гигантов как Google. Приходится тратить намало времени на поиск и анализ найденного. Кроме того, существует проблема достоверности найденной с таким трудом информации. Даже если вы нашли что-то нужное нет никакой гарантии что это нужное является реальным решением вашей проблемы. И, таким образом, перед нами актуализируется следующая задача: построение системы предоставляющей легкодоступную, точную и достоверную, структурированную и упорядоченную информацию.
И так далее. С моей точки зрения, оба этих проекта, если их получится реализовать, окажут громадное влияние на социум. Влияние сравнимое с появлением инета. Этот проект делает ненужным любые аутлайнеры. Ну почти Общественная база знаний такого качества меня (и многих) более чем устроит.

Я также имею определенные наработки в этой сфере и даже планирую сделать коммерчески успешный проект - интернет портал. Не хочу раскрывать всех подробностей, но так в кратце некоторые тезисы:
- пользователь имеет возможность формировать свою собственную базу аналогичную базе Web-каталогизатора on-line в рамках функционала какого-то сайта
- CMS такого сайта предоставляет возможность группировать и классифицировать базу каждого из пользователей как по категориям, так и по ключевым словам, которые как определяются пользователем, так и предлагаются самой CMS
- на каждую единицу сохраненной информации (вебстраницы или ее фрагмента) пользователь может давать свои заметки, выводы или комментарии. Существет возможность просматривать только слой комментариев, так и все вместе, так создавать еще один слой (выводов или заметок к комментариям)
- существует как дерево категорий, так и дерево ключевых слов, и оно может динамически меняться
- пользователь может давать/недавать доступ к своей базе всем желающим, или доступ только к слою комментариев и т.д.
- пользователь может давать указания CMS отслеживать инфо по определенным критериям и само-пополнять базу пользователя (скажем папку"неклассифицированное"
- группы пользователей и комьюнити могут вести совместную работу над формированием такой базы
так в кратце, а то уже жуть ли не ТЗ уже получается
- пользователь ничего не платит. за выполнение работ по заявке портала, пользователь может участвовать в выполнении платных заказов

igvis
xcode
ЕХ - лучше. ЕХ может быть не только документом. Это может быть любой объект, исполняемый файл, изображение, видео, звук.

Насчет пиринговой базы знаний с документами - вот http://www.scribd.com/ - что-то подобное. Правда не пиринговое.

Насчет информации на подумать.
Это раз - http://www.kinook.com/UltraRecall/ - по мне - так почти идеал, если еще сделать, чтобы хранилище лежало в Нете, так вообще здорово, плюс сделать, чтобы функции плагинами наращивались, как в FireFox.

И вот - http://www.evernote.com/ - хранится все в Сети. Клиент на десктопе, смартфоне. Тоже занятная база, правда все хранится одной лентой, но зато с тегами.

Если бы слить вместе UltraRecall, EverNote да к этому расширение функционала плагинами... Мечта бы реализовалась.

И насчет портабельности. Я неправильно выразился, имел в виду кроссплатформенность. То есть писать все надо на Java, AJAX и т.п. Чтобы не привязываться к Винде, Линуксу или чему бы то ни было. М?

Добавлено:
xcode
Да, и еще такая мысль. Может быть стоит, если уж все начинается с нуля, разрабатывать по другому принципу? То есть отталкиваться не от функций. Сами по себе функции не имеют значения. Программа должна решать задачи пользователя, а не просто быть скопищем функций, которые пользователь вынужден перебирать, чтобы найти нужные для себя.
Делать надо отталкиваясь от сценариев использования.
И еще мысль насчет разметки и форматирования. Надо полностью отделить содержание от оформления. Т.е. есть содержание, а есть таблицы стилей. Стили и определяют внешнее отображение информации. Т.е. так же, как это реализовано в CSS или OpenOffice. Кстати очень может быть стоит взять формат документов OpenOffice, благо он открытый, чем изобретать велосипед? В этом еще и тот плюс, что такая система будет хорошо вязаться с тем же OpenOffice, в частности документы можно будет редактировать в OO или вообще инкапсулировать его Writer, Impress, Draw и т.д. (возможно ли это?) в аутлайнер в качестве редакторов контента.

Со своей стороны могу принять посильное участие в разработке, правда я не программист, но ради хорошего дела можно и попробовать что-то изучить. Но опять же не думаю, что надо делать ТОЛЬКО на C++. Как минимум неплохо бы делать и что-то кроссплатформенное на той-же Яве или Руби, может быть с усечением некоторых функций, но зато обеспечивающее переносимость приложения с одной платформы на другую.

SFC
Смысл этой базы знаний - как раз в отказе от веба в привычном понимании этого слова. Скажем, я в пириновом режиме скачиваю пару сотен мегабайт электронной документации, затем отключаюсь от инета и она мне доступна в оффлайне. Даже при высоких скоростях интертена оффлайновая MSDN Library работает быстрее чем онлайн-версия - в том числе за счет того что все скрипты, как на стороне клиента, так и на стороне сервера, интерпретируются, а в оффлайн-версии работает оптимизированный машинный код. Ну и доступ в инет все равно никогда не будет быстрее чем доступ к HDD.
GingerFox
Про язык разработки: реально около 90% используюи винду, остальные линукс, те единицы которые используют что-то другое, как правило сами профессиональные программисты и в состоянии написать оболочку для себя, благо все открытое.
С++ - просто потому что мне так удобнее. Я реально рассматривал С++ или C#, написал на C# несложную программу для сканирования директорий и создания xml-образов... да, язык удобный - но С++ я уже знаю, есть куча готовых компонентов, а времени на изучение нового языка особо нет. А под линух можно кстати на qt написать, и под мак заодно Да и опыт такой разработки есть. Тем более, что я уже пишу код, не переписывать же на C# или Java

По форматам: ИМХО, html - более чем открытый формат Я не знаю какой там формат у OpenOffice, но наверняка ведь двоичный?
По функциям: я ставил UltraRecall, ничем особенным не впечатлила. Так и пользуюсь TreePad'ом

2All: Пишите пожалуйста конкретно функции, которые вам нравятся в том или ином продукте! Ставить и смотреть все просто нет возможности!. Кстати, это одна из целей создания этой темы

xcode
Уже пишешь... Стадию начального планирования по-моему не стоит недооценивать, если изначально все правильно продумать, то потом и делать будет гораздо легче. Насчет языка это конечно не камень преткновения. Надо четко продумать и описать все концепции и форматы хранения и обработки информации, тогда что-то доваять, сделать на другом языке будет намного проще.
HTML в качестве формата хранения не годится, слишком много ограничений, не пойдет.
Собственно нет у OpenOffice СВОЕГО какого-то формата. OpenOffice - открытый проект с открытыми исходниками (поэтому можно и позаимствовать че-нить типа...) и использует поэтому максимально открытые форматы, а не проприетарную хренотень, как мелкософт. Для хранения документов используется стандарт ODF - Open Document Format. Он НЕ двоичный, вкратце это XML запакованный в ZIP. Вот здесь Open Document Format Wiki кое-что об этом формате можно прочитать. Есть спецификация, переведенная на русский язык. Вот. Могу и спецификацию намылить или здесь выложить.

Я тоже уже давно ищу подходящий инструмент для сбора, сохранения и обработки информации, так может действительно стоит его сделать, но сделать ПРАВИЛЬНО. Изначально создавать, как максимально гибкий, расширяемый, чтобы не загнать себя в жесткие рамки каких-то ограничений, которые следуют из неправильных концепций и шагов с самого начала.

И еще раз - НЕ НАДО упираться в функции. Если изначально будет архитектура с возможностью подключения плагинов, то ФУНКЦИИ можно наращивать до бесконечности. Пример - FireFox. Сам по себе, в голом виде он просто платформа, зато наставив расширений можно выточить его в нужном для себя направлении. Кстати один из вариантов - наваять систему на XUL, а?
Так что не функции главное, а продуманная система организации данных. Если она будет изначально правильной, то функции в программах обработки уже можно будет накручивать по потребностям. А если не продумать как следует, то будет очередная частная поделка, которая так и останется частной поделкой.

GingerFox, а какие у html ограничения? нормальный формат, все что нужно для разметки и форматирования текста. Это НЕ издательская система, поэтому навороченного форматирования не нужно, а стандартный набор будет обязательно.

Цитата:

xml запакованный в zip

- ключевое слово "запакованный". zip - это уже двоичный формат, что непреемлемо для VCS. А "правильный" html - это фактически xml не запакованный ни во что. Метаданные будут храниться, естественно, в xml-файлах.
Выбор форматов обусловлен именно концепцией системы - многопользовательская и с контролем версий. Однопользовательских систем с закрытыми базами немеряно в теме "редакторы с древовидной структурой", а я как раз и занимаюсь реализацией принципиально новой концепции.

Никто не запрещает добавлять в html нестандартные теги и атрибуты - они просто не будут отображаться в стандартном IE редакторе, но до них можно добраться через DHTML и делать то что нужно по логике программы.

Стадия начального планирования уже давно идет На момент создания этой темы многие вопросы уже были рассмотрены (точнее, проект эволюционировал из стадии "а хорошо бы софтину с такими и такими возможностями" в стадию четкого понимания архитектуры и всех потенциальных возможностей). Затягивать дальше уже нельзя

Есть общая концепция - делать систему как можно более простой и открытой.

В настоящее время я разбираюсь с навороченным деревом с CodeProject'а - с функциями перетаскивания, мультиселекта, когда разберусь - протестирую новую концепцию размещения файлов. Уже тогда можно будет сделать простейший аутлайнер - на текстовых файлах, и затем разбираться с IE HtmlEdit'ом.

xcode
Пожалста, можно и не паковать, это уже не принципиально. Хотя было бы экономнее в плане объема на диске и скорости доступа. Может быть всю базу положить в упаковку, а вот внутри все сделать, как душе угодно.

HTML - ненененене! Дэвид Блэйн - ты демон! Лучше закладывать большие возможности, чем в какой-то момент упереться в ограничения только потому, что показалось, мол и так хватит. А чем же плохо, что можно будет любой документ взять из БД, отредактировать в OpenOffice, положить обратно и он будет сохранен со всеми изменениями? Да только благодарны будут все. Кому не надо, тот не будет пользовать возможности во всей полноте, а если понадобится, то такая возможность заложена. Ы?

Цитата:

а какие у html ограничения? нормальный формат, все что нужно для разметки и форматирования текста.

Полностью поддерживаю.

Цитата:

HTML - ненененене!

HTML - ДаДаДа!

Высказываю свое имхо:
Редактор с базой на основе HTML-файлов - это то, что я искал давным давно (и давным давно писал в теме про редакторы с древовидной структурой).
HTML - это формат, который при всей своей простоте позволяет выстраивать любые конструкции практически любой сложности. Говорю это как практикующий веб-дизайнер
К тому же, формат полностью открыт, и при желании просматривать полученные документы можно будет в любом браузере, а редактировать - в любом текстовом редакторе, хоть в "Блокноте".
Только почему-то писатели аутлайнеров об этом не думают.
Надеюсь, xcode будет первым, кто осуществит прорыв в этой области

От себя пожелание - предусмотреть кроссплатформенность изначально, то есть сразу делать полноценную версию не только под Windows, но и под Linux (без необходимости самостоятельной компиляции).
И еще одно пожелание - возможность экспорта отдельных веток или всей базы из ScrapBook (плагин для Firefox).

hammerit
Вам, как практикующему веб-дизайнеру, лучше многих должно быть известно, какие хитровые..нные вещи приходится накручивать кучами, и именно из-за убогости HTML. Простота его - из тех, которые хуже воровства. Нет бы сделать сразу нормальный формат хранения, не-ет, давайте будем так же геморроиться в "аутлайнере мечты", как в вебе.
xcode
А нельзя вообще сделать собственно костяк АМ (аутлайнера мечты ) таким, чтобы отображение в окне ЕХ (единицы хранения или заметки или как угодно, короче элемента дерева) делалось плагинами? А сами ЕХ были бы просто контейнерами, в которые можно закладывать что угодно - TXT, HTML, XML, DOC, RTF, OpenDoc, JPG, TIFF, GIF, RAR, ZIP, черта лысого. Тогда можно будет очень просто подключать хранение документов в любых форматах. Только РАДИ БОГА НЕ НАДО все перекосорыливать в HTML. Ну не универсален он ни фига. А если как я предлагаю, так и пожалуйста, кто хочет, все будет содить в HTML, а кому не хватит, подключит плагин и получит то, что хочет.
Вы же хотите сделать систему как можно более открытой? И это правильно. А вот как можно более простой - не надо пожаловста! Простых уже много, зачем их плодить.
А?

Еще разок прикинул. А ведь правда, хорошо так сделать - дерево, а отображение листов - плагинами. Тогда будет суперуниверсальная программа, любой сможет из нее сделать то, что ему надо, от файлового менеджера, до вьюера картинок. Со всеми промежуточными вариантами. Плагин отображения получает от дерева, что ему надо показать, а результат выводит в окно. Как-то вот так. Я не программист, может быть коряво выражаюсь, но идею постарался описать...

Контейнеры, в которые плагинами можно загружать разные форматы хранения данных - это конечно круто, мне нравится идея.
Только вот насколько это усложнит работу и утяжелит программу?
Нужно ведь не только отображать информацию определенного формата, но еще и редактировать ее... Соответственно, плагин для редактирования doc-формата должен представлять собой MS-Word в миниатюре... И так по каждому формату. Реально ли?

Народ, я полгода выбирал формат для основного типа документов То что он должен быть текстовый, было понятно сразу после определения идеологии (контроль версий, атвоматические слияния и т.д.). Сначала я думал найти какой-то bbcode-like редактор, затем думал использовать rtf редактор а при загрузке и сохранении использовать bbcode<->rtf преобразование... Но все гениальное просто, я увидел на CodeProject'е пример Html редактора и понял что это оно.

Плагин для MS-Word лично мне не нужен (точнее, нужан только читалка *.doc-документов, без редактирования, и то не сейчас а в отдаленной перспективе). Контейнеры как таковые будут - по крайней мере, после того как заработает html, я начну копать в сторону второго основного типа документов - векторных диаграмм. Это будут несложные xml-файлы, в которых будут храниться диаграммы различных типов, в основном то что нужно программисту. Разумеется, я подумаю о встраивании html в диаграммы и диаграмм в html. Что это будет - не знаю, как минимум - ссылки внутри базы и открытие связанного документа на отдельной закладке, как максимум - полноценное встраивание.
Контейнеры для "неродных" форматов - сама по себе задача значительно более сложная чем конрейтеры для родных. Трудоемкость разработки возрастает в разы, даже в десятки раз, а результат... все равно word, встроенный во что-то другое, будет глючить и тормозить, все равно все возможности офиса в плагин не запихать и вообще непонятно зачем это нужно. Так что будут внешние документы, подключенные в базу в виде гиперссылок, которые будут открываться в нормальном Ворде и там редактироваться.

Кстати, на счет кроссплатформенности. Может быть стоит посмотреть в сторону NVU - редактора HTML на движке мозилы? Тогда не будет привязки к винде.