Префиксы-суффиксы. Какой инструмент лучше использовать чтобы избавиться от префиксов?

[gl00mie]

Цитата:

Сообщение от mazzy

Не проблема написать. На лиспе, на си-шарп... да хоть на X++. КАК? Я ж и спрашиваю про инструмент и/или методику

Снова хочется вспомнить статью Джоэла Спольски "Где грязь, там и деньги" (цитировалась тут). Нет у этой сложной задачи простого и ясного решения - нужно повозиться, найти все "частные случаи" - тогда, может, появится полуэвристическая методика, которая, впрочем, не факт что будет работать на 100% в других условиях. За эту "возню в грязи" клиент и платит деньги хотя если по результатам родится некий инструмент, облегчающий решение таких задач, то будет здорово.

Цитата:

Сообщение от sukhanchik

Поэтому - я наверное склоняюсь к правилу 20/80. Т.е. переименовать 80% объектов за 20% усилий. Просто пойти по перекрестным ссылкам. Дальше вывести - список - чего осталось. Что-то действительно руками (возможно) быстрее сделать.

Полностью поддерживаю.

Цитата:

Сообщение от lev

так разве при заходе в аксапту, синхранизация выполняется автоматически

Часть таблиц - синхронизируется автоматически, см. \Classes\Application\syncApplTables, вызываемый в \Classes\Application\new. А еще вроде таблицы синхронизируются перед сравнением, вызываемым из формы импорта проектов.

Цитата:

Сообщение от mazzy

Хотя... Щас писал и подумал... А ведь если у нас есть таблица соответствий, то в ней можно и дубли отследить. ДО переименования. А затем выполнить замену в текстовом файле...

Замена в текстовом файле - штука небезопасная, потому что одно имя может оказаться подстрокой другого, т.е. как минимум нужно переименовывать в режиме поиска слова целиком или использовать регулярные выражения, и все равно может оказаться, что переименование безопасно проводить лишь в определенной последовательности, а не произвольно. Это схоже с проблемами скриптов обновления данных при переходе на новый SP/версию - в руководстве по их написанию акцентируют внимание на требовании к т.н. идемотентности.

PS. Вспоминаются давнишние рассуждения касаемо дефрагментации RecId (в частности, эти) - мне кажется, между этими задачами, если не вдаваться в технические детали, довольно много общего...

[mazzy]

Цитата:

Сообщение от gl00mie

Снова хочется вспомнить статью Джоэла Спольски "Где грязь, там и деньги" (цитировалась тут). Нет у этой сложной задачи простого и ясного решения - нужно повозиться, найти все "частные случаи" - тогда, может, появится полуэвристическая методика, которая, впрочем, не факт что будет работать на 100% в других условиях. За эту "возню в грязи" клиент и платит деньги хотя если по результатам родится некий инструмент, облегчающий решение таких задач, то будет здорово.Полностью поддерживаю.

Платит-платит.
И давай не будем путать сложные задачи с нерешаемыми задачами.
То, что задача сложная - вовсе не означает, что с ней надо возится бессистемно.

Вернемся таки к методике.
Похоже она таки есть. И сводится к замене в текстовом XPO-файле.

Предлагаю на обсуждение черновой вариант:
0. Подготовительная фаза
0.1. выгружаем строки из формы Пути к объектам в Excel-таблицу (со слоями)
0.2. отделяем пути от названия объектов
0.3. в Excel копируем названия объектов во вторую колонку
0.4. [опционально] оставляем только строчки с названиями объектов, которые могут быть переименованы (изо всех слоев, все названия). Например, оставляем (названия форм, датасорсов, методов), названия (таблиц, полей, групп, индексов), названия menuItem и т.п. Убираем label, documentation, контролы внутри форм, элементы внутри enum и т.п.
1. план переименования
1.1. во второй колонке Excel проводим черновое переименование объектов
1.2. во второй колонке Excel формулой находим возможные (с учетом путей) конфликты, дубликаты
1.3. разрешаем конфликты, вводя суфиксы или сохраняя префиксы
1.4. повторяем 1.1-1.4 пока не будут разрешены все конфликты переименования
1.5. в результате получили план переименования: в большинстве объектов префиксы будут удалены, но в некоторых объектах названия изменятся более сложным образом
2. Исполнительная фаза (воможен алгоритм от lev)
2.1. выгружаем слой в XPO
2.2. переименовываем согласно плана переименования (переименовываются как свойства, так и строки кода). Можно выполнять как вручную, так и с помощью каких-нибудь интеллектуальных макросов (типа Emacs). Можно и программку написать
2.3. загружаем измененный XPO
2.4. если во время загрузки получаем конфликты, возвращаемся на шаг 1.1.
3. Проверка
3.1. проводим глобальную компиляцию с уровнем детализации = 4 и со включением заранее выбранного набора рекомендаций.
3.2. если компиляция выдала ошибки и/или рекомендации - разбираемся с ними (возможно возвращаясь на шаг 1.1)

примерно так.
т.е. все-таки работаем с текстовым XPO.
но не механически, а на основании заранее подготовленного плана.

инструменты:
= excel
= xpo
= какой-нибудь продвинутый текстовый редактор, который умеет делать массовую замену по плану (текстовый файл)

[lev]

на мой взгляд план максимально выверен, должно нормально сработать. мелкие огрехи не исключены, но думаю на моменте компиляции и их можно будет исправить.
конечно не исключается человеческая работа (ну а куда же без неё ), но процесс по максимуму автоматизирован.

[sukhanchik]

Выгружаем в XPO конечно с сохранением id ? При загрузке XPO с id объекта с другим именем - АХ ругнется на то, что этот объект уже существует. Нужно после выгрузки XPO слой тереть. Либо переименовывать внутри АХ.

Кстати - еще момент. Помимо классов - есть еще и таблицы, названия которых присутствуют не только в АОТ, но и в БД. Так вот - если мы сохраним все id-шники (т.е. выгрузим в XPO с сохранением id, потрем слой, переименуем в XPO и загрузим с сохраненными id) - то нам достаточно будет просто запустить синхронизацию - т.к. АХ сама будет переименовывать поля и таблицы (если id в АОТе совпадет с id в SQLDictionary, а имена будут отличаться). Т.е. в этом случае никаких прыжков с удалением/восстановлением SQLDictionary делать не придется

[gl00mie]

Цитата:

Сообщение от mazzy

выгружаем строки из формы Пути к объектам в Excel-таблицу (со слоями)

Хм, речь ведь о xRefPaths?.. к слову, я себе для облегчения перехода на новые SP/версии приделал показ самого верхнего слоя в xRefPaths, чтобы можно было отделить ссылки, ведущие к модификациям, от стандартного приложения, щас выложу... А еще можно подцепить xRefNames и взять оттуда для каждого уникального имени идентификатор, тип, название родительского объекта...

Цитата:

Сообщение от mazzy

0.2. отделяем пути от названия объектов
0.3. в Excel копируем названия объектов во вторую колонку
0.4. [опционально] оставляем только строчки с названиями объектов, которые могут быть переименованы (изо всех слоев, все названия). Например, оставляем (названия форм, датасорсов, методов), названия (таблиц, полей, групп, индексов), названия menuItem и т.п.

По-моему, это обязательный этап, потому что на те же поля таблиц больше всего ссылок ("путей") дадут запросы - сами по себе и в отчетах.

Цитата:

Сообщение от mazzy

2. Исполнительная фаза
2.1. выгружаем слой в XPO
2.2. переименовываем согласно плана переименования (переименовываются как свойства, так и строки кода). Можно выполнять как вручную, так и с помощью каких-нибудь интеллектуальных макросов (типа Emacs). Можно и программку написать

Вот тут, мне кажется, и начнется самое интересное... Я бы все же при переименовании попытался использовать информацию из перекрестных ссылок, как это делает "Синтаксическое переименование", - так по усилиям/результату получится ближе к озвученному уже закону Парето. Переименование без семантической информации все же чревато: как вы, к примеру, отделите переименование поля XYZ_Name в Name от переименования метода XYZ_Name() в name_RNR() (при условии, что для метода возник конфликт имен, и решили сделать суффикс)?
У меня лично был такой "опыт" простого текстового переименования. 3-ка, как выяснилось, допускает использование в именах объектов приложения (как минимум методов) ту же кириллицу. Такой код прекрасно работает, пока не начинаешь пытаться запустить его на 2009-й - та резонно ругается при компиляции на чужеродные символы, а когда их заменяешь, начинает ругаться на код, в котором остались ссылки на названия с кириллицей. Одному разработчику это надоело, и он прошелся поиском-и-заменой, перебив в существенной части кода русскую строчную "с" на латинскую заглавную "C" (а, может, забыл включить учет регистра), в результате чего код-то изменился, но изменились также обширные написанные на русском комментарии, которые стали выглядеть м... "страшненько"

[BOAL]

Когда-то делал такое, но без такой мегасистемы. Возможно, так на так и выйдет по времени.
Тк предпочитаю "чувствовать" код, а для этого его нужно читать и ручками холить и лееять.
Итого алгоритм свелся к
1. выгрузить все в ХРО
2. Нотпад+ с УТФ поддержкой - Ктрл-R с не "заменить все", а с поштучной заменой, а то может найти не то по вхождениям. При этом шаг с ехелей и что на что - на бумажке или в голове
3. закачать все обратно - если там Глобал, Инфо и Апликатионс с Класс фактори не убиты, то проблем нет
4. Глоб компил и далее ходим и правим, че отвалилось (тут нужно иметь свой набор полезных тулов, тк на стандарте одни переходы через второй уровень поп-ап меню по ПКМ заколебет)

На большом слое (ХРО за 60мб) такая процедура заминаем 1-2 дня одного человека (с опытом подъема на слои, у которого реальный норматив 10-15мин на элемент в среднем)
Может даже и меньше занять по времени, но потом с чувством выполненного долга этот чел будет пинать балду, тк нервное напряжение сил и внимательность к мелочам утомляют.
А обсуждать это дольше чем делать.... как-то не практично
Но да, "семь раз отмерь - один раз закодь" - только у нас же не кирпичи, нам стену потом не ломать, что б на 50см сдвинуть, это все же строчки текста (хотя по времени равносильно может быть и по усталости исполнителя, но расходники не тратятся впустую).

Касательно ХРО - пока он в текстовом файле, а от версии к версии сравнение АХ все хромает и хромает (когда ж элементы формы будут стрелками тягаться со свойствами и прочие прелести), то я лично пришел к тому, что для переноса ах4-фх2009 было пользительно пользовать вообще сравнение текстовых файлов (кодерские тулзы с подстветкой синтаксиса) - так можно кликами (или Алт + стрелочки) тягать код и свойства.
Не всегда это быстрее сравнилки АХ, но по некоторым элементам дает прирост во времени в разы.
Опять же не восстанавливать форму (а по сути кодя ее с нуля), а именно объединять код было-стало.

[mazzy]

Цитата:

Сообщение от sukhanchik

Выгружаем в XPO конечно с сохранением id ?

Да, конечно.
про удаление, (не) синхронизацию и шаманство с базой - понял. Да

Цитата:

Сообщение от sukhanchik

Т.е. в этом случае никаких прыжков с удалением/восстановлением SQLDictionary делать не придется

Тоже понял. Но тут нужны будут эксперименты.

Цитата:

Сообщение от gl00mie

Хм, речь ведь о xRefPaths?..

Ага.
Подумав хорошенько понял, что, в принципе, можно выгрузить и любым другим образом. Например, программно пробегаясь по дереву AOT при помощи TreeNode.
Поэтому способ получения списка остается на усмотрение исполнителя-программиста. Как ему удобнее, пусть так и получает.

Главное - получить полный список объектов, которые могут влиять на переименование.

Цитата:

Сообщение от gl00mie

обязательный этап, потому что на те же поля таблиц больше всего ссылок ("путей") дадут запросы - сами по себе и в отчетах.

Я написал "опционально" поскольку это на усмотрение исполнителя. Вдруг ему будет удобнее работать с неочищенным списком.

Цитата:

Сообщение от gl00mie

Вот тут, мне кажется, и начнется самое интересное... Я бы все же при переименовании попытался использовать информацию из перекрестных ссылок, как это делает "Синтаксическое переименование"

А как это делает "Синтаксическое переименование"?

Цитата:

Сообщение от BOAL

При этом шаг с ехелей и что на что - на бумажке или в голове

Не, "в голове" не надо.
В том то и дело, что хочется найти методику, которая позволяет:
= распределить работу между несколькими людьми
= проконтролировать процесс исполнения
= убедиться что выполнено все (ничего не забыто)

Цитата:

Сообщение от BOAL

На большом слое (ХРО за 60мб) такая процедура заминаем 1-2 дня одного человека (с опытом подъема на слои, у которого реальный норматив 10-15мин на элемент в среднем)

Спасибо. Оценку понял.

Цитата:

Сообщение от BOAL

(когда ж элементы формы будут стрелками тягаться со свойствами и прочие прелести)

тягаются. alt+стрелки.

[BOAL]

Цитата:

Сообщение от mazzy

тягаются. alt+стрелки.

В ах2009 сравнилка стала лучше - факт. Но речь не о местах, где эти стрелки есть, а о местах, где их нет, а хотелось бы - вот там по ХРО можно сравнилкой по текстовым файлам пройтись.
В остальном ок.

Распределение такой работы по нескольким людям тут 99% выльется в известную фразу
"Ну, барин, за десять днев, тут без помощников не обойтись...."
Будет полноценный проект по переименованию, типа Дьюдилижанса, который был в одной фирме, перед продажей другой фирме....
Главное чтоб бюджет дали и все будут при деле - это не одному за 2 дня делать

===
К моей оценке - это токо перенос, тестить потом нужно 2-3 людям на сквозных примерах, и тут срок зависит от колва функционала - то есть может и в неделю-две перелиться. Так что, это действительно затратное дело.

[mazzy]

Цитата:

Сообщение от BOAL

В ах2009 сравнилка стала лучше - факт. Но речь не о местах, где эти стрелки есть, а о местах, где их нет, а хотелось бы - вот там по ХРО можно сравнилкой по текстовым файлам пройтись.
В остальном ок.

а... эти стрелки... да, согласен.

Цитата:

Сообщение от BOAL

Распределение такой работы по нескольким людям тут 99% выльется в известную фразу
"Ну, барин, за десять днев, тут без помощников не обойтись...."
... тут срок зависит от колва функционала - то есть может и в неделю-две перелиться. Так что, это действительно затратное дело.

да. и фраза пошла уже в том же сообщении
ну, это уже знакомая ситуация. с этим - справимся.