Pull to refresh

Comments 23

DokuWiki + в репу data/pages = довольно удобно как с точки зрения пользователя, так и с точки зрения писателя.
В связи с передвижениями по стране не всегда есть возможность доступа к интернету, а тут всё локально.
Была аналогичная идея, реализовал на Django, т.к. в случае дальнейшего развития идеи в Flask пришлось бы расширять модулями то, что в Django уже есть из коробки и хорошо работает (работа с БД, пользователи с ролями и очень много чего еще).

Ну и немного мыслей из разряда «что не хватает»:
1) Поиск
2) Версионность (можно реализовать любой VCS-системой)
3) Веб-редактор (особенно актуально для редактирования таблиц и вставки картинок, т.к. через текст неудобно)

То же кстати была идея на Django сделать что-то подобное. Но пока руки не дошли. Вы в открытый доступ не вылаживали ваш проект? Дадите ссылочку?
Извиняюсь, не так понял вопрос, не заметил ветку.
Там нечего выкладывать, т.к. код примерно такой же, как в проекте выше, только в реалиях Django. Развивать проект я не стал, т.к. пришел к выводу, что развивать это тяжело, долго и, пожалуй, не нужно.

Для начала я долго искал подходящий веб-редактор, и не нашел того, что мне нужно — а именно работу с таблицами и изображениями в одном флаконе. В итоге я продолжаю редактировать через Sublime, т.к. там есть прекрасный плагин Table Editor, позволяющий удобно работать с таблицами (что для меня критичным оказалось) и подсветка синтаксиса для вставок блоков кода. А для отображения в вебе при необходимости использую тот же Sublime с плагином Markdown Preview, который генерит на выходе вполне себе читаемый и приятный глазу HTML (single-file, т.е. все стили вшиты).

Поэтому пришел к выводу, что если и делать редактор для веба, то самый прямой путь — конвертировать html (с таблицами и картинками) в markdown, чтобы можно было при желании отредактировать то, что напечатано в markdown синтаксисе. А из этого вывода напрашиваются другие — а зачем тогда в markdown, если есть прекрасный чистый html? и как (и зачем) содержать две версии верстки одного документа? и т.д.

Все таки чистый markdown — сам по себе ограничен и подходит для сопутствующей документации, а не для полноценного документирования. А т.к. целью у меня было сделать подходящую замену блокноту Mars Notebook (переставшему развиваться и с отсутствующей синхронизацией), то применение wiki на базе markdown себя не оправдывало.

Извините за слишком развернутый ответ. Слишком много и часто об этом думаю, т.к. решения пока не нашел)
А что, если не секрет, вам нужно такого, чего нет в markdown разметке?
В разметке markdown мне всего хватает. Не хватает удобного инструмента для работы с этой разметкой.
Я вот тоже как-то болел вопросом где хранить заметки. Думал что буду писать на django своё что-то. Но сейчас вроде определился. Для разной инфы и записей юзаю Evernote. Для ведения проектов trello, для to do google keep, ну и для сниппетов кода и инструкций github gists. В принципе, вполне удобно. Разнобразие сервисов не мешает. Каждый для своего очень хорошо сделан. На этом я и остановился. Свой велосипед на джанго я думаю не смог сделать столь удобным для всех этих вариантов использования.
Позволю еще себе некоторые комментарии к реализации проекта (на правах «imho»):
  1. Метод hello() не нужен, т.к. он полностью дублирует функцию метода page() с пустым параметром. Лучше добавить условие в обработку параметра или задавать сразу значение по-умолчанию из конфига.
  2. Оптимизировав таким образом наше приложение до одной вьюхи, можно с уверенностью избавляться от остальных функций (проверка на наличие файла, конвертация в html и объединяющая их функция получения контента), т.к. все эти функции вызываются ровно один раз и логика в одном фрагменте будет прозрачнее, нежели разбросанная по функциям.
  3. И еще я бы конфиг занес в код приложения (в шапку) и избавился таким образом еще от одной функции разбора конфига.

В итоге от проекта можно оставить 2 файла — файл приложения с одной вьюхой и параметрами и файл шаблона.

Тоже давно искал то, что вы ищите. Остановил свой выбор на Turtl.
Тоже OpenSource, умеет markdown, шифрование и selfhosted, имеет стильный дизайн и собственное приложение. Поддерживаются все основные ОС.
Давно хочу написать о нем, да все руки никак не доходят...

Было бы неплохо если люди начали использовать commonmark спецификацию везде, а то зоопарк парсеров/рендеров очень усложняет работу с этим форматом. Почти всегда есть серьёзные несовместимости из-за неоднозанчости оргининальной спецификации.
Оооо, а ещё можно приятных стилей прицепить, и засунуть всё это дело в Electron. Правда, серверную часть в таком случае имеет смысл на JS реализовать.
В свое время искал облачное решение для заметок с образцами исходных кодов, с поиском и тегами.
В итоге сделал свой велосипед.
Js tree не помню,
mirror code как редактор и хайлайтер кода
Select2 для тегов
Bootstrap frontend
Php backend

В общем-то результатом доволен, вполне юзабельно. Есть куча вещей для улучшения, но так лень… :)
Зачем, когда есть просто куча статических генераторов сайтов написанных на python? Вы по сути сделали тоже самое, только с меньшим количеством возможностей. Я для своих заметок и блога выбрал pelican. Помимо всего прочего, есть дополнения чтобы прикрутить самый различный функционал (мат. формулы, TOC, etc).
Sign up to leave a comment.

Articles