относительно проекта lindocs
В Базе Знаний на сервере добавлен материал относительно продолжения
развития проекта lindocs. Читайте. Высказывайте свое мнение.
Присоединяйтесь к проекту.
Подписаться
Бесплатный дискуссионный лист
Подписчиков 97
| ← Ноябрь 2004 → | ||||||
|
4
|
6
|
7
|
||||
|---|---|---|---|---|---|---|
|
9
|
||||||
|
21
|
||||||
|
28
|
||||||
За последние 60 дней ни разу не выходила
Сайт листа:
http://kirov.lug.ru
Открыт:
15-09-2003
Пре-модерация: Нет
Адрес для писем в лист: comp.soft.linux.kirovlug-list@subscribe.ru
Модератор
Статистика
97 подписчиков
0 за неделю
0 за неделю
Ответы:
как здорово, Стас, что ты объявился... Как у тебя дела?
да...
Ну если этим кто-то займется, то я не против - мне просто некогда и этим
тоже заниматься...
или
+
очень сложная система для оценки... хотя что-то подобное было бы очень
полезно... Я было подумал ставить ценность/информативность по
10(5)-бальной шкале, но понял что это субъективно, и лучше оценивать
несколько мнений - это сложно для offline проекта... Надо над этим еще
думать...
если будет написанный клиент - то именно это он и будет делать... но
всегда нужно иметь возможность html-го представления - здесь-то и нужна
иерархия - для облегчения поиска...
согласен, я тоже предусматривал такое, но я плохо знаю возможности XSLT
преобразования (хотя и стараюсь пополнить свой запас знаний по этому
вопросу), поэтому не стал затрагивать пока эту тему...
GUI будет нужен... Можно что GTK (можно пихать на диск с архивом
док-ии), что Swing (JVM поставить - не такая большая проблема для
участников проекта)... Если человек является просто читателем доки, то
может использовать просто html-страницы для навигации... На крайний
случай XML - обычный текстовый файл - можно поправить руками...
Доброго времени суток, Саня.
Я "объявился" пока только в сети, поскольку физически я
сейчас в Усинске, где пробуду как минимум до середины января.
Радует появление в списке дистрибутивов долгожданных фильмов ;)
Да, вполне понимаю.
Я думаю что при выборе из 3 категорий споров и субъективности
будет мало. Хотя нужно сделать формулировки более конкретными.
А для электроныых версий книг, вообще говоря, нужно будет
отдельную категорию. Но на всё это ещё есть время.
Можно получить ту же самую иерархию произведя выборку по основным
ключевым словам. Но преобразование имеющейся документации
к такому виду действительно займёт много времени.
Я предпочёл бы GTK, но пока не уверен что у меня будет время на эту
часть проекта.
Вдруг набегут поклонники Java-ы и сразу всё напишут... :)
Впрочем, я был бы рад такому обороту дел ,)
з.ы. В таблицах стилей сайта, при описаниях границ (border)
элементов, лучше уточнить единицы измерения (вместо 1 писать 1px),
потому что иначе при определённых условиях (например, страница, как
вывод cgi-скрипта), это обрабатывается неправильно.
я вот подумал: еще на конференции разработчиков, на которую я ездил мне
предложили как платформу для документации использовать Zope. У Zope есть
собственная реализация http-сервера... Т.е., наверное, можно рядом с
документацией положить Zope, которую запускать как http-сервер и весь
интерфейс (получается web-интерфейс) и логику описать на Zope. Т.е. если
тебе нужно просто пошарится в доках, ты листаешь обычные html заранее
сгенерированные, если ты хочешь, что-то добавить или изменить, то
запускаешь Zope (требует Python) и в этом же браузере работаешь c базой
ссылок...
Данное явление нужно проанализировать глубже...
Доброго времени суток, Kolotov
Thursday, November 11, 2004, 2:55:44 PM, you wrote:
База ссылок? А как быть с контентом который тоже давно уже требует
приведения его к нормальному виду... (например, преобразовал
пару книг по Perl из lindocs, к виду удобному для представления
в единой базе: единая таблица стилей + одна кодировка + удаление
баннеров и скриптов - в результате некоторые из них уменьшились
на 60%).
Предлагаю изенить формат хранения данных полностью, т.е. номинально
это будет тот же html, пусть даже в едином стиле оформления,
без скриптов банеров и прочих "обломков дизайна" и т.д.
НО, каждая книга будет в отдельной директории и в той
же директории будет храниться xml файл с описанием книги/статьи,
а скрипты будут уже потом всё это собирать в единое целое...
Статьи, поскольку их много, можно наверно размещать, при
необходимости, в одном каталоге, но тогда и описание их будет
в одном файле.
Плюсы - единая система хранения данных и их описания,
можно делать "срезы" базы при необходимости (т.е. например,
запустив скрипт можно из базы получить локальную выборку
на интересующую тему, или по автору, (см. далее ктаегории статей) и
скопировать из базы только то, что действительно нужно), простота
преобразования такого представления к уже привычному - тому которое
предлагаешь ты.
Статьи делятся на категории с помощью указания ключевых слов, авторов, даты
публикации, а также такой малоконкретной категории, как "практичность" - она
определяет, несёт ли эта статья достаточно большую информационную нагрузку или
является "руководством к действию" и для глубокого понимания может потребовать
чтения дополнительной литературы. В этой категории я предпологаю три варианта
theory - теория, article - статья, может включать в себя описание действий +
их поясдение, и recept - конечный алгоритм действий ("рецепт"), практически
без пояснений (такими могут быть файлы конфигурации и т.п.).
+ преобразование "контента", к нормальному виду, достаточно трудоёмко,
поэтому при желании можно разделить это на части...
я уже начал делать это с Perl документацией, так что, продолжу именно
с ним.
Вопросы/ответы:
parent будут определять уровень вложенности?
А может обойтись без такой строгой иерархии и делать просто выборки
по ключевым словам? Или конечное представление на машине пользователя
так и останется статичным html-ем?
Можно принять неопределённое значение за normal.
Лучше оставлять пустым, или даже так и писать: <author>Неизвестен</author>
What do:
Наверное, это будет не скрипт а XSLT преобразование, которое,
уже в свою очередь можно выполнять вручныю/скриптом/...
GUI нужен будет? А какой у нас GUI кроссплатформенный? GTK, но его вряд
ли будешь под Win* ставить и Java Swing, для использования которого
нужна JVM. Остаётся ещё, конечно Web-интрефейс, но у него тоже свои
требования.