| 
			
			 | 
		#1 | 
| 
			
			 Боец 
		
			
	 | 
	
	
	
		
		
			
			
			Отделение объектов АОТ в разрезе функциональности.
			 
			
			Есть приложение, в котором на ОДНОМ СЛОЕ разработаны независимые друг от друга функциональности (для простоты - модули). Но проекты в которых собраны элементы AOT per модуль потеряны. Встала задача перенести один из модулей в другую систему, т.е. собрать все элементы АОТ, относящиеся к интересуемому модулю в проект экспортнуть. Вставала ли подобная задача у кого-нибудь? Как решалась (интересует эффективное решение, не перетаскивоние по-нескольким элементам и дотаскивание чего не хватает)?  
		
		
		
		
		
		
		
	Идея которая мне пришла в голову - написать инструмент примерно такой 1. На вход подаем один из элементов для интересующего модуля (напр. MenuItem из главного меню). 2. Далее, начиная с этого MenuItem'а, он рекурсивно, обнавляя и используя crossRef, бежит по всем related-элементам глубоко вниз и находу вытаскивает их в отдельный проект, учитывая нужный нам слой (слои). На первый взгляд такой пробег должен собрать все (или почти все) нужные элементы. Каково ваше мнение? Может есть другие идеи?  | 
| 
	
 | 
| 
			
			 | 
		#2 | 
| 
			
			 Мрачный тип 
		
			
	 | 
	
	
	
		
		
		
		 
			
			По перекрестным ссылкам он Вам натащит даже то, что не является Вашей разработкой, а является стандартными объектами AOT
		 
		
		
		
		
		
		
			
				__________________ 
		
		
		
		
	Мы летаем, кружимся, нагоняем ужасы ...  | 
| 
	
 | 
| 
			
			 | 
		#3 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Обычно все кастомные объекты должны иметь префикс. 
		
		
		
		
		
		
		
		
			Создайте проект и пофильтруйте его сделав селект по объектам с нужным вам префиксом (например ХХХ*). Останутся только модифицированые стандартные объекты, которые в свою очередь могут быть модифицированы обоими солюшенами. Их тоже ищем с помощью фильтра: utilLayer = 'usr'; ModifiedDate = '>01/01/2007' (посмотрите дату любого немодифицированого сис объекта - зависит от вашей версии АХ). Последний раз редактировалось Mykola Galak; 11.07.2008 в 15:11.  | 
| 
	
 | 
| 
			
			 | 
		#4 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			согласно последнего постановления ВЦСПС не префикс, а суффикс. 
		
		
		
		
		
		
			
		
		
		
		
	префикс должен определять модуль.  | 
| 
	
 | 
| 
			
			 | 
		#5 | 
| 
			
			 Боец 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
		
			...он Вам натащит даже то, что не является Вашей разработкой, а является стандартными объектами AOT
		
	 
Цитата: 
	
		
			Обычно все кастомные объекты должны иметь префикс.
		
	 
 | 
| 
	
 | 
| 
			
			 | 
		#6 | 
| 
			
			 Участник 
		
			
	 | 
	
	|
| 
	
 | 
| 
			
			 | 
		#7 | 
| 
			
			 Axapta 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Терпеть не могу префикс у объекта согласно коду фирмы/проекта, к которому он относится. Префикс должен обозначать модуль. Ужасно неудобно, когда не помнишь, стандартное это поле, например, или добавленное. Приходится, чтобы его найти сначала без префикса попробовать, а потом с префиксом. Это если префиксов два. А если больше? Так что польностью согласен с Маззи. Более того, я даже не считаю нужным делать суффикс. 
		
		
		
		
		
		
		
	miklenew, а зачем вам это надо, чтобы "Всё в одном месте(на одну букву), а не разбросано"?  | 
| 
	
 | 
| 
			
			 | 
		#8 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Потому что, как правило когда задачу начинаю делать. 
		
		
		
		
		
		
		
	Что нибудь когда нибудь да делал. В память какая нибудь зацепочка для поиска есть. Выделил например все классы с префиксом и поиск. А если по всему AOT дольше возиться, чтоб отобрать что нужно.  | 
| 
	
 | 
| 
			
			 | 
		#9 | 
| 
			
			 Боец 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Ушли от темы, по-моему оффтоп начался...
		 
		
		
		
		
		
		
		
	 | 
| 
	
 | 
| 
			
			 | 
		#10 | 
| 
			
			 Axapta 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
Извиняюсь. Можно выделить в отдельную тему.  | 
| 
	
 | 
| 
			
			 | 
		#11 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			А если это в нескольких прилагах. 
		
		
		
		
		
		
		
	Сегодня из одной, завтра из другой. Причём стоящих на локале. Не выход.  | 
| 
	
 | 
| 
			
			 | 
		#12 | 
| 
			
			 Axapta 
		
			
	 | 
	
	
	
		
		
		
		 
			
			При разработке надо думать прежде всего не о своем удобстве, а об удобстве того, кто это потом будет поддерживать и дорабатывать. А ему от ваших префиксов пользы мало. Вы же не один работаете над этим приложением. 
		
		
		
		
		
		
		
	А "модуль" - большой? Объектов таких много? Вручную не будет эффективнее? Я бы так делал, а не программировал какой-то новый инструмент.  | 
| 
	
 | 
| 
			
			 | 
		#13 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
Тогда: 1. не занимайтесь ерундой (в смысле, не программируйте новое) 2. соберите все измененные объекты в один проект. Сервис \ Средства разработки \ Обновление \ Мастер создания проекта для обновленных объектов (Точное название не помню) 3. Создайте группы в проекте: Подпроект1, Подпроект2, Общие объекты 4. руками растащите объекты по разным группам. Уверен, что так вы получите результат быстрее и надежнее (даже если у вас несколько сотен измененных объектов), нежели писать код, потом его тестировать, а потом выверять результаты.  | 
| 
	
 | 
| 
			
			 | 
		#14 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
И этот же префикс ставят другие программисты. И пока было удобно. И мне и другим.  | 
| 
	
 | 
| 
			
			 | 
		#15 | 
| 
			
			 Axapta 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Так же ужасно выглядит, когда есть какой-то стандартный класс Cust***, а вы добавлаете ему наследника, но называете его не Cust***_MyChild, a, например, Doors_Cust***.  
		
		
		
		
		
		
		
	![]() Цитата: 
	
+1  | 
| 
	
 | 
| 
			
			 | 
		#16 | 
| 
			
			 Боец 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
		
			А "модуль" - большой? Объектов таких много?
		
	 
 | 
| 
	
 | 
| 
			
			 | 
		#17 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
А в остальном всё правильно. Тоже будет ставить MRD_. Толк познается в работе. Я сразу вижу наше это или стандартное. Или чьё-то ещё.  | 
| 
	
 | 
| 
			
			 | 
		#18 | 
| 
			
			 Боец 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Ок, всем спасибо, будем разруливать...
		 
		
		
		
		
		
		
		
	 | 
| 
	
 | 
| 
			
			 | 
		#19 | 
| 
			
			 Axapta 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Для этого слои есть.Надо у проектов делать префикс той компании, которая разрабатывает. Таким образом легко собрать все вами созданные/модифицированные объекты и никому мешать это не будет. 
		
		
		
		
		
		
		
	Ок, как скажите.   Просто надеюсь, что мне не придется работать в приложении, в котором у объектов есть некий лишний префикс. Тем более, что у "ВЦСПС" такое же мнение.Просто был опыт. Очень не понравилось. Доходило до того, что даже не только методы начинались с префикса, но и переменные. Представьте себе переменную MRD_i.  | 
| 
	
 | 
| 
	
	 | 
	
		
  |