Каталоги и файлы являются в настоящий момент самым распространным способом навигации по коду. Но на мой взгляд не очень удобным. Например, у меня открыто 10 проектов и я хочу быстро перейти к классам, которые используют рейтинг игрока. Навигация по каталогам такого удобства мне не предоставляет, прийдется вспоминать в каких именно классах я использоваль рейтинг, потом открывать пару каталогов и сам класс. И повторить эту операцию N раз.
В ходе дебатов родилась такая идея – к стандартной навигации добавить навигацию по тегам. Программист в комментах для класса описывает теги – @tags rating user battle. А плагин для Eclipse отображает данные теги в виде облака и позволяет быстро открывать нужные классы и файлы.
Вот такая идея. Реализовать бы 
Альтернативная навигация по исходникам в Eclipse
Запись опубликована в рубрике Программизмы с метками Идеи, Программизмы. Добавьте в закладки постоянную ссылку.
8 комментариев: Альтернативная навигация по исходникам в Eclipse
Добавить комментарий
Для отправки комментария вы должны авторизоваться.
Я для схожих задач использую Mylyn. Достаточно удобно – он связывает таски с редактируемыми файлами, запоминая окна с которыми ты работаешь во время выполнения задачи. И затем при переключении между тасками сам открывает нужные и закрывает ненужные окна. + учет времени.
Сейчас думаю попробовать его с Jira. Спасибо, кстати за пост про sales акцию.
Mylyn и я использую и именно с Jira. Работает отлично, но все же это не то что хотелось бы от тегов, хотя и помогает.
Простите за оффтоп, Алексей. Но вот не понятно мне, чем так замечательна технология OSGi?
Что она дала лично для вашего проекта? Можете назвать список преимуществ перед обычной динамической загрузкой классов?
И еще, не напоминает ли этот фреймворк старый добрый COM, от которого Майкрософт последние годы усиленно пытается избавиться?
OSGI хорошо позволяет разделить интерфейсы от реализации, а также одного программиста от другого, например список закрытых и открытых классов в плагине. В общем то и все + всякие сервисные возможности, типа консоли, замена плагинов на лету и пару других мелочей.
Ядро OSGI само по себе в jar занимает кил 100, то есть мизер. И еще оно отлично ложится на Maven, прямо душа радуется.
Например для запуска сервера на удаленной машине надо иметь две вещи – pom.xml и maven
при запуске он поттягивает все нужные модули из нашего репозитория и оп ля – запустился.
В общем для проектов с плагинной структурой или с большим количеством разработчиков – самое то, особенно если нужен не стандартный подход – например для игрового сервера. Для бизнес логики лучше все же взять jboss и подобное.
Sun готовит новую спецификация для jdk7, где будет описано использование «модулей».
Появится возможность запаковывать всю ту информацию, которая сейчас суется в бандлы.
Просто теперь это будет реализовано на уровне jdk.
как говорится обещанного три года ждут
Было много дискуссий на тему того, почему Sun изобрела велосипед, а не воспользовалась стандартом OSGI.
В общем OSGI зрелая технология, которая поддерживается крупными вендорами, так что я за неё.
Ну так тому и быть!
Может после присоединению к Оракулу в Сан-е начнут трезвее мыслить…