SASGIS - SAS.Планета |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0002693 | SAS.Планета | Рефакторинг | public | 22-04-2015 10:43 | 22-04-2015 13:31 |
|
| Reporter | zed | |
| Assigned To | zed | |
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | |
| Platform | | OS | | OS Version | |
| Product Version | 141212 | |
| Target Version | 150915 | Fixed in Version | 150915 | |
|
| Summary | 0002693: Отсортировать юниты в SASPlanet.dpr |
| Description | Мне уже давно не нравится тот хаос, что творится в uses в dpr файле (особенно, необходимость лазить туда руками, после добавления нового юнита).
Хочу отсортировать юниты по имени и поддерживать сортировку в автоматическом режиме. Для этого написал скриптик на питоне (в аттаче).
Возможные варианты сортировки: по имени юнита или по его пути. Мне больше нравится сортировка по имени. По пути, юниты сортируются в dproj самой делфи.
Сортировка не затрагивает системные юниты и юнит SASPlanet.modules. |
| Steps To Reproduce | |
| Additional Information | Помимо сортировки, скрипт помогает при перемещениях юнитов по папкам в файловой системе. Использование весьма простое: файловым менеджером перемещаем юниты как хотим (главное не переименовывать юнит), запускаем скрипт и получаем валидные пути к юниту в файлах проекта (dpr и dproj).
Данный скрипт хочу положить в папку Tools. |
| Tags | No tags attached. |
| Relationships | |
| Attached Files |  UnitsSortHelper.py (4,605) 22-04-2015 10:44
https://bugtracker.sasgis.org/file_download.php?file_id=1855&type=bug |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 22-04-2015 10:43 | zed | New Issue | |
| 22-04-2015 10:43 | zed | File Added: SASPlanet.by_unit.dpr | |
| 22-04-2015 10:44 | zed | File Added: SASPlanet.by_path.dpr | |
| 22-04-2015 10:44 | zed | File Added: UnitsSortHelper.py | |
| 22-04-2015 10:44 | zed | Note Added: 0015660 | |
| 22-04-2015 10:53 | vasketsov | Note Added: 0015663 | |
| 22-04-2015 10:53 | vdemidov | Note Added: 0015664 | |
| 22-04-2015 11:13 | vasketsov | Note Added: 0015669 | |
| 22-04-2015 11:13 | vasketsov | Note Edited: 0015669 | bug_revision_view_page.php?bugnote_id=15669#r6539 |
| 22-04-2015 11:21 | zed | Note Added: 0015670 | |
| 22-04-2015 11:24 | vasketsov | Note Added: 0015671 | |
| 22-04-2015 11:29 | vasketsov | Note Edited: 0015671 | bug_revision_view_page.php?bugnote_id=15671#r6541 |
| 22-04-2015 12:55 | vdemidov | Note Added: 0015672 | |
| 22-04-2015 13:19 | zed | Note Added: 0015673 | |
| 22-04-2015 13:19 | zed | Status | new => resolved |
| 22-04-2015 13:19 | zed | Fixed in Version | => 150915 |
| 22-04-2015 13:19 | zed | Resolution | open => fixed |
| 22-04-2015 13:19 | zed | Assigned To | => zed |
| 22-04-2015 13:20 | zed | File Deleted: SASPlanet.by_path.dpr | |
| 22-04-2015 13:20 | zed | File Deleted: SASPlanet.by_unit.dpr | |
| 22-04-2015 13:31 | vasketsov | Note Added: 0015674 | |
|
Notes |
|
|
(0015660)
|
|
zed
|
|
22-04-2015 10:44
|
|
|
У кого какие мысли, возражения? |
|
|
|
|
>или по его пути
Так представляется логичным вот почему: поскольку файлы раскиданы по папкам, то изменения с большей вероятностью затронут меньшее количество строк в dpr.
А вообще конечно не принципиально.
Но вообще если решите так формировать dpr и dproj - тоже перейду на этот скрипт, только вот дополнительные файлы куда-то деть надо будет (в отдельный модуль видимо).
>главное не переименовывать юнит
А что страшного будет, если юнит переименуется?
Старый пропадёт, новый появится. Diff-ы видно же. Чай не 100500+ файлов меняется за раз. |
|
|
|
|
|
Я за сортировку по пути. А еще лучше было бы сначала сортировать по префиксу в имени юнита, а потом уже по пути. Причем префиксы отсортировать не по алафавиту, а по предварительно заданному порядку: t_*.pas, c_*.pas, i_*.pas, u_*.pas, fr_*.pas, frm_*.pas |
|
|
|
|
>i_*.pas, u_*.pas
Хм. А чем плохо, если будет так:
i_BinaryData in 'Src\Basic\i_BinaryData.pas',
u_BinaryData in 'Src\Basic\u_BinaryData.pas',
u_BinaryDataByFileMapping in 'Src\Basic\u_BinaryDataByFileMapping.pas',
u_BinaryDataByMemStream in 'Src\Basic\u_BinaryDataByMemStream.pas',
i_BinaryDataListChangeable in 'Src\Basic\i_BinaryDataListChangeable.pas',
i_BinaryDataListStatic in 'Src\Basic\i_BinaryDataListStatic.pas',
u_BinaryDataListStatic in 'Src\Basic\u_BinaryDataListStatic.pas',
То есть, u_ цепляем к существующему i_, если такового нет, то смотрим какой максимальный есть (CamelCase тут рулит) и цепляем туда, сортируя среди всех его u_?
Не вижу смысла разделять "одноимённые" i_ и u_ пропастью в половину файлов проекта.
|
|
|
|
(0015670)
|
|
zed
|
|
22-04-2015 11:21
|
|
>А что страшного будет, если юнит переименуется?
Скрипт его проигнорирует и не исправит файлы проекта.
>А еще лучше было бы сначала сортировать по префиксу в имени юнита
По-моему, фигня получится. |
|
|
|
(0015671)
|
|
vasketsov
|
22-04-2015 11:24
(edited on: 22-04-2015 11:29) |
|
>проигнорирует и не исправит
Упс. А я понял, что скрипт просто строит часть файла проекта заново по фактическим файлам в каталогах, просто берёт начало и конец файла, а середину с файлами и путями с нуля собирает.
>фигня получится
Никогда не понимал, зачем все формы так яростно совать в самый конец проекта.
Так что уж лучше при сортировке вообще игнорировать префикс, чем такая вот фигня с перечнем префиксов.
XE2 вполне корректно обрабатывает ситуацию внешнего изменения фалов проекта (в том же блокноте), так что после запуска скрипта среда вполне в состоянии будет сама поднять его с диска, и лазить руками в файлы проекта не понадобится, соответственно, какой там порядок, важно только для самого порядка и изменений, а не для правки руками. И где будут frm - сугубо пофигу.
|
|
|
|
|
>Хм. А чем плохо, если будет так
>То есть, u_ цепляем к существующему i_, если такового нет, то смотрим какой максимальный есть (CamelCase тут рулит) и цепляем туда, сортируя среди всех его u_?
Нетривиальная сортировалка выходит.
>>фигня получится
>Никогда не понимал, зачем все формы так яростно совать в самый конец проекта.
Может быть и фигня. |
|
|
|
(0015673)
|
|
zed
|
|
22-04-2015 13:19
|
|
|
Отсортировал по пути и залил в репо. Для запуска скрипта нужен python 2.7. |
|
|
|
|
>Нетривиальная сортировалка
Ну в общем-то да, не сильно тривиальная.
Но это проблема скрипта и принципиального наличия консенсуса в том, что это вообще НАДО. А то если например кто-либо будет руками править dpr, то толку будет мало.
Поскольку мне тоже кажется предпочтительнее по папкам раскидывать, алгоритм вижу примерно такой:
а) скрипт берёт файл проекта, ищет начало списка модулей и его конец (весьма тривиально по характерным строчкам в файле проекта, что для dpr что для dproj);
б) проходит по дереву каталогов, строит его и в алфавитном порядке для каждой папки выполняет следующие шаги;
в) получает исходный список файлов;
г) сортирует i_ в чистый результирующий список (из исходного на каждом шаге обработанное удаляется);
д) добавляет в этот список все u_ (по алгоритму выше, это как раз самое нетривиальное);
е) добавляет в этот список все прочие файлы, для которых есть в точности одноимённый i_ или u_, непосредственно ПЕРЕД ним или любым другим с другим префиксом и той же смысловой частью имени файла (чтобы t_ и c_ соответствующие i_ были перед ними, но реализацию в u_ от i_ не отделяли) *);
ж) остальное сортируется между собой тупо по алфавиту (для форм и фреймов оставляется одна соответствующая запись вместо двух имён файлов в dpr) и помешается в результирующий список в начало (для простоты, а также если будут ещё новые префиксы);
з) результирующий список обрабатывается и падает в файл проекта;
и) цикл повторяется, покуда не прошли все каталоги;
*) если на шаге е) в список попадают одноимённые формы и фреймы, значит разработчик сделал это неспроста, и их тоже надо обработать на этом шаге аналогичным образом.
Поскольку краеугольным камнем проекта является именно интерфейсный файл i_, а реализация его в u_, подобный алгоритм представляется весьма оправданным.
А поскольку бардак в dpr существенно разросся с увеличением папок в проекте, делать всё равно что-то придётся. Например, я просто руками с разделяющими комментариями раскидал всё по папкам. Но идея со скриптом мне нравится больше. Особенно если его напишет уважаемый товарищ zed )))
Осталась самая "мелочь" - прийти к консенсусу. |
|