Можно ли в FD создать фиктивное разбиение файлов проекта по подкаталогам?
 

Попробовал перейти с CS3 на FD и столкнулся с такой проблемой: в CS3 все классы проекта были в одном пакете а в ClassExplorer они были раскиданы по подкаталогам фиктивно (т.е. помещение файла класса в отдельный подкаталог не влекло за собой его физического перемещения и изменения имени его пакета, а было чисто внешнее, для удобства). Меня этот подход устраивал. В FD же помещение файла класса в подкаталог влечет за собой его физическое перемещение в подкаталог, что соответственно отражается на имени его пакета. Можно ли в FD сделать так же как в CS3 - поместить файл в поддиректорию только для удобства его последующего поиска, не перемещая его физически и не меняя имени пакета?

Нельзя

Жаль, неудобно тогда очень выходит. Если перетащил один файл просто для удобства, придется менять все импорты во всех классах, где есть на него ссылка.

Наоборот удобно. Это дело привычки.

у меня в последнем проекте 1739 классов, эх прикольно их в одну папку свалить

Если бы он импорты менял бы автоматически, тогда еще да. А FD только названия пакетов меняет автоматом. Я, наверное, лучше на CS3 останусь пока :(

Добавлено через 30 секунд
А какой средой пользуетесь?

1. Надо сразу создавать классы в нужном пакете, а не таскать их туда-сюда. А это приведет к тому, что будете заранее продумывать иерархию и делать меньше ошибок.
2. Даже если перенесли класс, то исправить ручками импорт займет немного времени. Если импорт точный (с указанием имени класса), то простой ctrl+i заменит пути за секунды, если импорт общий (вместо имени написано *), то займет больше времени. Просто запустите компиляцию и у вас выпадет список ошибок импорта, жмем F12 и перемещаемся по списку файлов и быстро меняем. Это все займет меньше времени, чем вы тратите работая с кодом в CS3.

Спасибо, Кэп :)
Я только одно спрошу - вы на практике это проходили? Когда большой проект и нужно сегодня так, а завтра ровно наоборот?

В CS3 у меня все классы в одном пакете. А иерархия в отдельном файле и отображается в ClassExplorer. Мне вообще не приходится думать об импорте классов проекта друг в друга. Так как это физически может занять больше времени?

VIM, FD, IDEA.

Вашу проблему, наверное, все "проходили" на практике. Проблема из-за проблемы(не стоит писать код во Flash IDE)

Проблема не в этом, я посижу пару часов и пролинкую все, что нужно. Вы, исходя из практики работы с проектом >1к классов, расскажите, как решаются подобные трудности? Например нужно перенести классы из кнопок из пакета interface в пакет interfase.buttons ?

Это разработчику архитектуры проекта надо по шапке давать за такое, когда сегодня одно подавай, а завтра другое. Сами сказали что проект крупный. И если он писался на коленке - это не проблема средств разработки. Это проблема в разработчиках.

Разделять классы на пакеты нужно. Возьмите в пример стандартные наборы классов и ответьте сами на вопрос, почему класс Event находится в пакете events, а не в display или вообще в корне.

А ответ на последний вопрос - в комменте iNilsа.

Если у вас больше 1к классов, то...
Понимаете, любая Flash IDE, будь это CS3 или CS6, не предназначена для нормальной работы с кодом. Это возможность есть, но наследство от самых первых версий. Когда я еще писал на AS1, то перешел на редактор Scite, потому что само редактирование кода в нем удобнее и приятнее. Переход на AS2, а потом и на AS3 привел меня к FD. Тут выигрыш еще больше. Мощный автокомплит, мгновенный переход к исходнику класса, собственные шаблоны, сниппеты и тп. Просто пример, допустим вы пишите код, который в голове уже представляете. Скажем в FD на его написание и редактирование у вас уйдет 5 минут, а в CS 10 минут (время условное). Сколько будет выигрыш во времени, если вы напишите 100 классов? 500 минут! А сколько вы потратите на изменение пакетов? С помощью того, что я писал выше, явно не эти 500 минут.
Откуда берется выигрыш во времени?

Допустим вам нужно создать два цикла вложенных друг в друга. Вы пишите ключевое слово сниппета и жмете Ctrl+B, вам сразу выпадает диалоговое окно, где уже проставлены имена счетчиков i,j (можно изменить) и начальное значение 0 (тоже меняется), вам остается только указать конечно значение и Enter. У меня ушло 8 секунд и я получил
Сколько у вас уйдет на это в CS? У меня 23 секунды. Почти в 3 раза медленнее.

И такие мелочи вы используете постоянно, в отличии от смены имени пакета, отсюда и выигрыш во времени.
Начнем с того, что нужно думать чуть вперед. Почему эти классы оказались у вас в interface ()? Когда создаете класс, то вы должны думать примерно так:
1. Это визуальные объекты, следовательно основой будет пакет (домен и имя проекта мы не трогаем, считаем, что они уже есть), в котором будут содержаться все подобные классы. Называем его ui или gui.
2. Кнопки могут быть разные. Например системные кнопки, а могут быть кнопки клавиатуры. Создаем для них еще папку, получаем ui.keyboard
3. Далее сами кнопки ui.keyboard.button
4. Длина пакета может быть еще больше, вы все таки представляете что вы делаете в итоге.

А если вы по умолчанию сразу все примитивно видите, то конечно, у вас всегда будет потребность расширять пакет.

В Идее - выбираем файлы > Refactor > Move.. Все импорты и комментарии(по желанию) исправятся автоматически.

Не пойму к чему демагогия: в FD "фиктивного разбиения файлов" нету, есть find and replace. В других IDE есть дополнительные способы.

2 iNils

Спасибо, ваша точка зрения понятна.

У меня получается немного по-другому.
Я наверное не профессионал :) Я по умолчанию вижу все как раз примитивно. Моя практика подсказывает, что как бы задача не ставилась, все равно потом придется все переделывать. Например в своем хобби-проекте я сначала сделал обработку квестов в клиенте. Замечательно, все работает, но при эелементарном стороннем воздействии на флешку, результат выполнения квеста мог быть подделан. Первая полная переделка - перевожу работу с квестами полностью на сервер. Опять же все работает, но появляется заметное отставание при получении каждый раз полной копии данных по квесту в клиенте. Полная переделка вторая - частично восстанавливается работа с квестом в клиенте и делается синхронизация измененных данных с сервером, за которым оставляется физический контроль над выполнением. В итоге результат удовлетворительный, но я не уверен, что не придется еще раз все переделать. А за три переделки куча классов появилась, удалилась, поменяла имена и функционал. Возможно для крутого профи это все очевидно с первого взгляда, для меня - нет. Я прохожу через поле с граблями. Поэтому вопрос постоянной реорганизации для меня достаточно важен.

По поводу скорости работы - я, опять же исходя из практики, замечаю, что основное время уходит не на задалбливание кода, а на его продумывание, чтобы все работало как мне надо и без сбоев. Поэтому выгадывание секунд при набивании на мой взгляд не так важно.
Вот автокомплит мне удобен, но посмотрев на автокомплит в FD, я как-то его застращался. Ввожу:
нажимаю пробел, чтобы вводить дальше " = new ...", получаю:
WTF ?? С какой стати автокомплит подменил введенный мной класс совершенно другим? На исправление уходит гораздо больше секунд, выгаданных за счет любых ускорений.

В общем я понял, преимущества сводятся в основном к удобству работы. Пока останусь на CS, единственное, что немного напрягает, периодически проскакивающие фразы о том, что CS не любит большого количества классов, отказывается компилировать, а у меня количество уже перевалило за 300.

А где находится класс Edit?

Добавлено через 9 минут
Так происходит, когда FD не может найти в ближайшем окружении этот класс.
Автокомплит пытается по введенным символам найти подходящий класс или список классов, они показываются в всплывающем контекстом меню и нажатие на пробел считается как выбор класса, который выделен в этом меню. Поэтому, если класс еще не создан, то перед нажатием на пробел нужно нажать Esc, это отменит автовставку. А чтобы потом произошел импорт, на классе Edit нажать ctrl+shift+1
И как можно работать с 1000+ классов без автокомплита? Наизусть все помнить?

Существует в том же пакете. Я просто скопировал все классы из проекта в CS3. FD нормально собирает, правда только для 9 плеера, для 10 и выше что-то не так компилирует. А вот с автокомплитом такая засада. Когда в одном случае работает, а в другом нужно esc жать, очень неудобно. Проще тогда совсем отключить.

300+ я работаю, в принципе проблем особых с запоминанием нет.
Проблемы могут тут быть, если не один человек работает с кодом, но пока я все делаю сам.

А пакеты там верно указаны?

Все в одном пакете.

Простите. 300+ классов в одном пакете?

Да. И я никак не пойму, почему это вызывает такую реакцию.

Пробуй еще. Это многое прояснит.

Я не знаю с чем можно будет провести правильную аналогию, но всё таки попробую.
Представьте себе, что имя класса – это имя песни, а пакет – её исполнитель. Музыку Вы сортируете по каталогам, исполнитель-альбом-песня. Но Вы же хотите Ваши 300 песен положить в одну папку. Если эту песню запустить – да, сразу станет понятно, кто её исполнитель. Но вот как-то это... не инутитивно совсем.

Класс UserInfo, например. О чем Вам говорит? Это информация о пользователе. Но вот только это совсем неодзначный ответ, а если с каталогом
то сразу всё чудесней и понятней.

При навигации по Open Type/Resource это очень весомая подказка, при навигации выбором класса мышкой это... ё-моё, это шанс на выживание.

А если у двух разных исполнителей будут песни с одинаковыми названиями - пиши пропало.

Ну если явно пакет не указывать - то пропало.

Об этом и речь.

2 Psycho Tiger
В итоге все сводится лишь к удобству. Меня вполне устраивает, когда все лежит в одном месте. Пакет у меня ассоциируется с проектом. Все что принадлежит проекту находится в одном пакете. Если мне нужно поискать по иерархии, в ckassexplorer у cs3 вся иерархия отображается. И она совсем не должна быть физической, для того, чтобы ее использовать.
Возможно рано или поздно, я тоже приду к тому, чтобы делить классы по пакетам. Пока справляюсь так.

Странный разговор. Новичок рассказывает профессионалам про свое видение организации проекта, апеллируя к единственному единомышленнику — Flash IDE — которого, в свою очередь, никто никогда не считал сколь-нибудь достойной средой разработки Flash приложений. Прекрати "ассоциировать пакет с проектом" и слушай, что тебе опытные товарищи говорят.

Придёте-придёте. Пока вы делаете проект один - вас может устраивать вообще всё. Но даже через год взглянув на него вы с трудом вспомните что ж это за 932 класс и к чему он относится.
Вон видите, даже такая задача как смена среды написания кода выросла в тему на 3 страницы. И дело не только в удобстве.