Новое в Elisy.CfInspector v1.2:
Добавлено распознавание форматов epf/erf/cfu дополнительно к cf
В объекте Configuration поддерживаются свойства BriefInformation, DetailedInformation, Copyright, VendorInformationAddress, ConfigurationInformationAddress, разделение по видам объектов
Распознавание объекта Enum без расшифровки свойств
Новое в Elisy.CfInspector v1.1:
- Распаковка image-объектов в виде подкаталога с файлами;
- Распознавание имен для общих модулей, отчетов и обработок;
- Переименование известных свойств согласно именам 1С;
- Исправлена ошибка чтения cf-записи с нулевой длиной;
Утилита Elisy CfProject выгружает файлы в формате, совместимом с CF-файлами 1С:Предприятие, в удобочитаемые Xml и текстовые файлы, а также загружает их обратно. Утилита оформлена в виде внешней обработки 1С:Предприятие 8.2 и требует предустановленного .Net framework 4.0 и Elisy .Net Bridge 4.0.3. Самым близким аналогом утилиты является V8Unpack.
Утилита предназначена для организации контроля версий через SVN, GIT, Mercurial , для помощи при восстановлении испорченных файлов конфигураций, а также для изучения внутренней структуры cf-совместимых файлов.
Здесь представлен прототип Elisy CfProject CTP для всеобщего ознакомления с технологией. Условия распространения еще не определены. В основу утилиты положен проект Elisy MdInternals, предназначенный для программного доступа к объектам конфигураций.
На входе в утилиту поступает cf-файл, на выходе – cfproj-файл и дерево каталогов с выгруженными файлами. Распознанные файлы помещаются в соответствующие подкаталоги. Нераспознанные – в каталог Unresolved. Распознанные файлы преобразуются в xml-формат, в то время как нераспознанные записываются «как есть».
Основные возможности
Проект написан на C# и .Net framework и оформлен в виде сборок. Это позволяет без особых проблем обращаться ко всем свойствам и методам объектов из кода 1С через Elisy .Net Bridge.
Распознанные файлы записываются в дерево каталогов по видам объектов:
[more]
Распознанные файлы выгружаются в XML-структуру. Это делает их совместимыми с многими просмотрщиками, позволяет контролировать логическую целостность формата файлов, а также обрабатывать их программно сторонними средствами:
Распознанные свойства перемещаются в соответствующие разделы (атрибуты или тэги) XML-структуры:
Нераспознанные текстовые файлы во внутреннем формате, совместимом с 1С, переформатируются в удобочитаемый вид для будущего анализа:
Была предпринята попытка увеличить быстродействие за счет многопоточности
Что не реализовано в данной версии
В данной версии реализовано распознавание только файлов конфигураций, не реализовано распознавание внешних отчетов/обработок и CFU-файлов.
Утилита распознает только объекты конфигурации 1го уровня, помещая их по подкаталогам. Не распознает все остальное: формы, макеты, помещая все в каталог Unresolved
В каталоге Unresolved не распаковываются составные объекты с расширением img.
Для примера реализовано распознавание свойств только одного объекта: Функциональная Опция с отражением в Xml-структуре
Работа проверялась только на одной конфигурации.
// //
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Разработчики платформы на последнем семинаре анонсировали выгрузку/загрузку конфигурации в XML-формате средствами самой платформы в одном из ближайших релизов — предположительно уже в 8.2.16.
(1) Скорее всего там будет опять же лишь небольшой процент содержимого конфигурации (модули, тексты интерфейса и т.д.).
(xml) все это конечно круто. Но как собрать сие добро обратно. Сейчас самая актуальная проблема это выгрузка форм и макетов так как с программным кодом более мене все понятно 5есть стандартный механизм есть V8Unpack которые выгружают все в более менее удобочитаемом виде.
соглашусь с (2)
ВСЮ конфу в екемель? — да никогда.
это ж барабан на встречу
(1) Это отличная новость — выгрузка XML проблему контроля версий охватит. На повестку дня встанет программный доступ к объектам конфигураций для создания «на лету». CfProject и MdInternals будут переориентированы в этом направлении.
(3) CfProject собирает все, что нараспаковывал, обратно
А, собственно зачем такие танцы??? Ни кто не отменял бэкап скула или дт.
(5)
Молодец
а что эта программа сделает с модулями, которые не включены в поставку?
и с запаролеными обработками?
(2) Вся конфа будет выгружаться, во всяком случае — так было заявлено.
Ибо звучало так: «можно выгрузить и загрузить обратно».
Таким образом, если хоть что-то не выгрузили — что мы же мы потом загрузим? 🙂
Интересно что оно делает из формой или с макетом или с запароленными модулями, нужно будет посмотреть!
(7) Как-то работа с cf и ваше предложение о dt- sql- архивах не согласуются. Не могли бы вы мысль немного развернутей описать? 🙂 Спасибо
не плохо, респект
(10)(12) Не стоит слишком много ждать от прототипа. Думаю, что утилита поместит такие модули в Unresolved-каталог «как есть».
Хотя в Elisy MdInternals есть зачатки функционала декомпиляции opcode-модулей, которого хватает, чтобы понять суть декомпилированного модуля, но CfProject этот функционал не использует.
На C# декомпиляция через объект класса Elisy.MdInternals.Cil.CodeReader выглядит примерно так:
public static void UnloadCommonModules(Image image, string folder) { MetadataPackage md = new MetadataPackage(image); var requestModules = from o in md.MetadataObjects.AsParallel() where o is CommonModule select new {Content = o.ImageRow.Body.ToString(), FileName = o.ImageRow.FileName }; var requestContent = from module in requestModules.AsParallel() join ir in image.Rows.AsParallel() on module.FileName + «.0» equals ir.FileName //orderby module.Content select new { Module = module.Content, Image = ((Image)ir.Body).Rows.Where(i => i.FileName == «image»).FirstOrDefault() }; var files = requestContent.ToArray(); foreach (var file in files) { if (file.Image == null) continue; string fileName = file.Module; fileName = fileName.Substring(fileName.IndexOf(‘»‘) + 1); fileName = fileName.Substring(0, fileName.IndexOf(‘»‘)); string opCodeString = file.Image.Body.ToString(); using (StreamWriter outfile = new StreamWriter(folder + fileName + «.opcode»)) { outfile.Write(opCodeString); } CodeReader reader = new CodeReader(opCodeString, true); string decompiledString = reader.GetSourceCode(); using (StreamWriter outfile = new StreamWriter(folder + fileName + «.txt»)) { outfile.Write(decompiledString); } }Показать
В общем — декомпиляция модулей — это тема отдельной статьи. Если будет интерес, постараемся сделать примеры с кодом 1С.
Спасибо! Интересная вещь!
Можнло поэсперементировать при загрузке. Серьёзная штука
Кому тяжело скачивать Elisy .Net Bridge 4.0.3 с англоязычного форума, выложили дистрибутив на Инфостарт здесь:
За старания +. Очень интересная штуковина
Всем спасибо за комменты!
А исходничков не будет?
Плохая идея, пока выгрузишь, а тем более соберешь, УПП — состаришься. Кому оно вообще нужно — конфа в xml?
(22)
В первую очередь нужна конфа в xml или другом читаемом формате для систем версионирования. 1С-ники работают с хранилищем конфигурации, не догадываясь, что научный прогресс шагнул далеко вперед.
На втором месте — испорченные конфигурации, которые можно выгрузить и руками исправить.
Далее — автоматическое создание конфигураций и обработок, автоматизация операций конфигуратора.
Как-то так.
(23) именно xml плохая идея. Покажите мне нормальную diff алку для xml файлов, а потом говорите, что xml хорош для систем версионирования. Hg, git, bzr рекомендуют для xml файлов ставить признак binary, что бы система не делала автоматических merge.
автоматизация операций конфигуратора: каких интерестно?
(24) pumbaE,
xml хорош тем, что можно проверить целостность каждого файла через соответствие открывающих и закрывающих тэгов. Это распространенный формат, поддерживаемый многими в мире. Имеет текстовое наглядное представление, поэтому распознается и хранится системами версионирования как родной формат. Первый раз слышу о рекомендации ставить на него признак binary. Будьте добры предоставьте ссылку на такую рекомендацию, а то непонятно в каком контексте это нужно понимать. Тысячи проектов на Asp.Net, PHP живут в СВН без этого признака, являясь по сути XML-подобными (html со вставками кода).
К слову сказать, не вся функциональность CFProject документирована. Этот проект позволяет делать выгрузку не только в xml, но и в родной для 1С формат со множеством фигурных скобок.
Навскидку — автоматизировать замену всех комментариев реквизитов Организация в документах или поиск и замена во всех ячейках в макетах конфигурации. Написание своих визардов по созданию форм, макетов.
(25) мне понятно стало, что с xml и версионым контролем вы активно не работали.
Поясню:
, svn покажет красиво различия в xml, если структура не менялась, а только содержимое элементов, то конечно все просто и красиво, пример , но вот такой распространенный случай как : в объект конфигурации добавили слово удалить и добавили новый объект с тем же именем, svn не решит и понять в выводе diff будет сложно, т.к. автоматическая решалка конфликтов, предложит оставить наименование без «удалить».
(26) pumbaE,
понятно, что всегда бывают конфликты и не только в xml, но и с исходным кодом других проектов.
Напомню, что обсуждение началось с того, что было высказано сомнение в формате xml, как взятого за основу в обработке. Как обоснование приведено сравнение версий в (26). Но тогда возникает вопрос, какой формат будет более подходящим? Сколько приходит на ум потенциальных форматов, везде будут конфликты с переименованием реквизита в «удалить» и добавлением нового одноименного при автоматическом решении конфликтов.
Не проверял, но писали где-то, что проект Mercurial более стойкий к такому виду конфликтов, так как спроектирован был специально для этого.
Интересное решение, кто-нибудь реально использует в работе? Впечатления, выявленные недостатки?
(28) AlexanderKai,
сомневаюсь, что кто-то использует в работе. Все ждут 1С 8.3, где ожидается схожая функциональность при выгрузке конфигурации в облака.
(15) Функциональность декомпиляции в будущих версиях будет вынесена из проекта Elisy.MdInternals как провокационная для лицензионной политики 1С. Хотя эта операция разрешена в ГК РФ.
Декомпилирование модулей расширено и опубликовано on-line по адресу:
Как и обещала компания 1С в 8.3 добавлена выгрузка конфигурации в xml-файлы. Но почему этот процесс занимает так много времени?! 🙂
(30)
Замеченна проблема у сервиса:
Проблема с кавычками внутри строк: вместо «чччч «»Текст в кавычках внутри строки»» yyy» возвращается «чччч «Текст в кавычках внутри строки» yyy». Поэтому после завершения необходимо выполнить проверку модулей.
(30)
И ещё одна:
Перепутано расположение параметров при установке параметров запроса: вместо “Запрос.УстановитьПараметр(«Дата», Дата);” сервис вернул “Запрос.УстановитьПараметр(КъмДата, «Дата»);”
(30)
Похоже проблема с порядком параметров обща, т.к. перепутан порядок парамтеров и в определении функций и процедур. Сервис вернул: «Функция ХХХХХХ(Парам2, Парам 1) Экспорт» — параметры должны быть в другом порядкеНаврал. с этим все ок, но вот с передачей параметров ошика есть:
Вызов функций: «Новый ХранилищеЗначения(Новый СжатиеДанных(), ДвДанные)» — сжатие — это второй параметр.
Ну и с запросом выше — тоже самое.
(32) Resha,
Проблема с кавычками внутри строк: вместо «чччч «»Текст в кавычках внутри строки»» yyy» возвращается «чччч «Текст в кавычках внутри строки» yyy». Поэтому после завершения необходимо выполнить проверку модулей.
(33) Resha,
Спасибо за баг-репорты. Библиотека подправлена. В новой версии 1.0.0.5 эти проблемы должны решиться.
Вы можете проверить прямо сейчас на сайте:
В связи с популярностью разработки решено выделить немного ресурсов для ее развития.
Если у кого есть пожелания, пожалуйста, делитесь.
Многие возможности уже реализованы, но не документированы. Возможно, многие проблемы и пожелания уже можно решить на программном уровне.
В будущем курс будет взят на формат файловой выгрузки конфигурации 1С 8.3 для совместимости.
проверил на «битой» конфигурации.
sql1c.epf — выдала кучу собщений об ошибке и ничего не распаковала.
v8unpack — справилась с задачей.
(37) МихаилМ,
v8unpack — справилась с задачей.
Можно узнать, какая связь между CfProject и обработкой sql1c.epf? Я не нашел такую обработку в списке файлов для скачивания.
(38)
виноват конечно Elisy.CfProject.epf
+
«битый» cf
(39) МихаилМ,
Не скачивается. Долго думает, потом после выбора куда скачать скачивает файл с 0 байт.
(40)
«битый» cf
configsave.7z
(41) МихаилМ,
Скачать удалось.
CfProject состоит из 2х уровней: 1й — работа на уровне записей cf-файла — отвечает класс ImageReader
2й — уровень метаданных, из записей cf-файла строится связанная структура (класс MetadataPackage).
Ошибка, описанная вами, происходила из-за позиции 22F файла, где запись дана с 0й длиной. Ее поправили и получилось прочитать 10297 записей.
Но этого недостаточно для 2го уровня, так как нет точки входа — записи с именем «root». Соответственно после устранения 1й ошибки появилась неустранимая ошибка — невозможно найти запись с именем root.
Максимум, что можем предложть — дать доступ средствами 1С к таблице записей cf-файла image.Rows. На C# код будет примерно такой:
Но готовых процедур выгрузки/загрузки записей, как в v8unpack пока нет. Поэтому не знаю как это может вам помочь.
(43) artbear, я хочу написать свой v8unpack в виде ВК NativeAPI, с блэкджеком и прочими атрибутами 😉
но базироваться планирую на лазарус
(45) artbear, да, лазарус на базе FPC реализован
так вроде полно шаблонов есть.
(43) artbear,
Давно использую подобные инструменты.
Хочу присоединиться к какой-нибудь разработке и знаю разработчиков, также готовых помочь в разработке подобных инструментов.
Пока примериваюсь к v8unpack, как наиболее открытом и вполне рабочему инструменту.
Была подготовка к большей открытости. Например, вынесено декомпилирование модулей в отдельный проект. Без этого действия 1С не дала бы жизни проекту, преследуя открытое распространение.
Но после выхода 1С 8.3 с возможностью выгрузки конфигурации в файлы целесообразность разработки CfProject оказалась под вопросом. Возникло несколько вопросов: кто будет пользоваться, если в 1С есть функционал «из коробки»? Кто будет участвовать в проекте, если даже после открытия исходного кода v8unpack никто не присоединился к его разработке?
Если проект интересен сообществу, то мы можем рассмотреть возможность публикации под GPL-лицензией на GitHub.
(44) andrewks,
но базироваться планирую на лазарус
Как говорится, планировать одно, а сделать — сложнее. Опять же вопросы: кому нужен функционал после выхода 8.3?
CfProject — C#-проект в основе которого сидит .Net-сборка Elisy.MdInternals.dll с функциональностью:
1. Нижний уровень
Чтение-запись cf-файлов
Парсинг-сериализация «{0,{..}}»-подобных строк
2. Верхний уровень
Построение структуры на основе cf-записей, распознавание объектов конфигурации.
Так как это .Net-сборка, то все ее классы и функциональность доступна через Elisy .Net Bridge из кода 1С и внешних обработок или из любых .Net-проектов. Портировать сборку на Mono 2.8, думаю, труда не составит.
(48)
да нет там ничего сложного. единственная проблема — время, которого катастрофически не хватает.
насчёт «кому это надо» — потребность есть. конкретно свою реализацию я планирую как одно из ответвлений проекта , ибо даже после выхода 8.3 умирающие файловые базы никуда не исчезнут. ну, а как другое направление — как раз разбор cf в текстовые файлы для svn и прочих
(48) кстати, с выходом 8.3 сами длл-ки на .NET оказываются на очень интересном положении, ограничивающим применение конкретной ОС
(49) andrewks,
насчёт «кому это надо» — потребность есть. конкретно свою реализацию я планирую как одно из ответвлений проекта , ибо даже после выхода 8.3 умирающие файловые базы никуда не исчезнут. ну, а как другое направление — как раз разбор cf в текстовые файлы для svn и прочих
Когда я говорил, что сложно, я не имел ввиду — невозможно для среднего ума. Я имел ввиду комплексно время + навыки + дальнейшая поддержка. Направление разбора cf для SVN охватывает 8.3 с выгрузкой в формате XML, как я понимаю.
(50) andrewks,
Нет в этом положении ничего интересного: не будет .Net, будет Mono.
Но пока в NativeAPI не появится IDispatch-подобный тип, стандарт останется ущербным по сравнению с COM ВК.
Кроссплатформенность в 1С для ВК — это миф. Чтобы быть NativeAPI ВК идеально кроссплатформенной, это разработчику нужно поддерживать зоопарк дистрибутивов:
Windows + Linux + plugin для IE + plugin для FF + plugin для Chrome + plugin для Opera
помноженное на 2 (32х и 64x)
Сомневаюсь, что кто-то располагает такими ресурсами. А значит и кроссплатформенности не будет.
(51) по вопросу «Направление разбора cf для SVN» лично я считаю, что это ещ должно было быть реализовано штатно в 8.0, ну, на крайняк в 8.1. но 1с не ищет лёгких для пользователей и разработчиков путей
(52) согласен, NativeAPI ущербна, ведь функционал-то есть, чтобы замутить нечто подобное, но см. (53) последнее предложение
(53) andrewks,
1C прагматична. В принципе для коммерческой программы оправдано. Выгрузка в файлы появилась для публикации конфигурации в облаках и, как реакция, на популярные разработки типа v8unpack. Специалисты из 1С наверняка мониторят сообщество на предмет новых фич в свои продукты. В 8.4 нужно ждать скорее всего Снегопата ))))).
(56)
Например, ранее не было такого явного перехода на 8-ку опытных разработчиков с 7-ки, группы разработчиков не так сильно задумывались о коллективной разработке и т.д. и т.п.
имхо,
1С не выходил из сегмента фикси-программистов-саппортеров (существенно, я имею ввиду).. а там ничо такого не надо
как только пошел достаточно массовый выход на отраслевые проекты, требующий серьёзной командной разработки — так тема и стала актуальной:
выгрузка/загрузка в 8.3
атоматическое тестирование в 8.3
сертификация эксперта по техн. вопросам
ЦКТП
это всё одного поля ягоды — обеспечение технологической базы для выход на средний, нижне-крупный сегмент заказчиков
и, кста, явный провал сейчас скорее не в технологии, а в управленческих методиках работы в таких проектах. Программистов толковых много, а тимлидов, РП и прочих — по пальцам…
В теме, кто знает, достаточно давно. Пример работы используемого мной средства разборки/сборки cf-файлов смотрите
(заказная оплаченная разработка)
Кратко об инструменте: названия папок мнемоничные, модули выгружаются в текст, формы в текст с фигурными скобками, таблицы в mxl, картинки в картинки, служебные файлы, в служебные и т.д.
Область применения: является элементом используемой технологии управления распределенными программными проектами для v8 (проекты промышленного масштаба).
Из опыта эксплуатации: подтверждаю мнение (24) pumbaE, о плохой идее тотальной xmlизации выгруженных файлов, но допускаю, что где-то есть «золотая середина» — что-то надо однозначно в текст, но что-то, вероятно, лучше будет работать (выгрузить/загрузить), как xml. И, да, xml в CVS лучше живет бинарным. Ранее хранили, как текст, но после пары граблей от хранения текстовым типом отказались.
Желание: необходимо локализовать и подправить несколько известных багов и, возможно, развить (оптимизировать), чтобы облегчить технологию взаимодействия с CVS (пока сильно уступает в эффективности gcompу, задействованному в проектах на 7.7).
Возможности: могу предоставить площадку для разработки, тестирования, посильное финансирование, в целесообразности открытия проекта и вообще, в распространении этого инструмента, как самостоятельного продукта (вне зависимости от типа лицензии) пока сомневаюсь. Этот инструмент, пока, как скальпель — в одних руках спасает жизнь, в других может смертельно ранить 🙂
(43)
(44)
Давайте вместе 🙂
Начало у меня уже есть —
Как раз Lazarus использую.
Могу выложить код (на github, например).
(58)
А смысл тогда учавствовать, если полученный результат не будет никак распространяться?
(59) Magister, на чём базируется? на TStream, надеюсь?
(61)
Нет, а зачем? 🙂
Примерно так:
И дальше работа с памятью. Так быстрее, чем через TStream.
(62) Magister, хмм… и как, интересно, Вы это собирались компилить для линукс?
(62) Magister, кстати, я не был бы так категоричен в утверждении, что отображение быстрее TStream.
если размер буфера в TStream подобрать оптимально, то разницы практически не будет
(63) Примерно вот так:
(64) Возможно, я не разбирался как работает TFileStream. Возможно разница не будет большой, не проверял.
Но однозначно будет быстрее полного чтения файла в память.
Кстати, можно сделать MapViewOfFile а потом скормить его в TMemoryStream 🙂
Получим единый интерфейс.
(66) Magister, ок, я подумаю. в любом случае, рутина не позволит приступить к этому вопросу раньше февраля. отпишусь
(65) Magister,
это уже не банальная компиляция, это почти переписывание отдельных участков, в то время, как TStream даёт больший универсализм. впрочем, если линукс как одна из целевых платформ не стоит, то, может, и не стоит заморачиваться
(67) ок. у меня тоже рутины сейчас завались, потому и нет пока дальше развития той публикации…
(68) Переписывать нужно только пару функций — открытие файла и закрытие. Они возвращают адрес в памяти и размер, а дальше ничего не меняется — т.к. идет работа с памятью.
(68) (69) Я не мешаю вам со своими комментариями и C#? :))))))))
(60) Magister, смысл участия каждый определяет для себя самостоятельно. У меня достаточно зрелый работающий продукт, с многолетним опытом промышленного использования, в вашем, еще только «возможно, в будущем будет сделана сборка…». Думаете, мне интересно, возвращаться на 6 лет назад — к началу разработки моего инструмента? 🙂 Хотите распространять свой — пожалуйста, кто ж вам запретит? Хотите распространять мой или совместный — обсуждаемо, но сначала необходимо определиться с целями распространения с учетом различных интересов участников. Известное дело, поговорили, собрались, низкий старт, потом начинается, у одного «рутина», у другого — поигрался и отдал, у третьего — увидел, «соблазнил и овладел», понял, что «жалкое подобие правой руки», пропал интерес 🙂
(56) artbear,
Куда вам отправить исходники для предварительного ознакомления? Вам лучше сначала на них посмотреть. Может, там не то, о чем вы думали и что планировали увидеть.
(72) AlexWhite,
Не хочу вас огорчать, но проект 6-летней давности мог морально устареть. За это время очень многое поменялось. В логе Python 2.2 выдает язык, на котором написан проект. Специалистов под него мало, особенно среди 1С сообщества. Я не видел проектов на Инфостарт, применяющих Python. Судя по тексту в блокноте до полного парсинга метаданных вы так и не дошли. Есть частичный парсинг для построения дерева, но сути не меняет.
Смысла скрывать проект нет. Судя по оживленной теме здесь появляется куча разработок, аналогичных v8unpack. Начинается конкуренция. Конкуренцию выиграют бесплатные, открытые и кому выделяются ресурсы.
Ресурсы нужны. Особенностью таких проектов является необходимость регулярно уделять внимание проекту, так как 1С время от времени вносит изменения в структуру метаданных и новые метаданные. Изменения были в 8.2.13, 8.2.15, (вроде 8.2.17), 8.3
На питоне написаны скрипты для используемой WinCVS — клиента CVS. Скрипты действительно взрослые, как и сама CVS, но дорабатывать их лишено смысла, они исправно исполняют то, ради чего создавались.
Затрудняюсь понять, что вы понимаете под полным парсингом метаданных. В блокноте открыл форму — для демонстрации примера, как она разбирается в текст и модуль — тоже текст. Для CVS разделение типов файлов принципиально, для бинарных каждая версия хранится целиком, для текстовых — оригинал + отличия от оригинала, что позволяет оперировать ветвлением (branch), слиянием (merge). А вы пробовали merge для xml + успешно собрать после этого cf? 🙂
Сам проект на Delphi, но это вторично. Мне было важно, чтобы программа была написана для определенных целей, в разумный срок, за приемлемую плату. Нашелся желающий, выбрал инструмент, написал, заработал денег.
Да, хоть, целая свалка! От использования своего инструмента откажусь тогда, когда найду другой, превосходящий по необходимым мне потребительским качествам. Ищу постоянно, ковыряясь в появляющихся кучах поделок, пробую новые технологии. И, тоже не хочу вас огорчать, но даже вашей, достаточно симпатичной, судя по приведенным снимкам экрана, разработке еще очень далеко до того момента, когда она станет пригодна для промышленной эксплуатации. Почему по снимкам? Хотел развернуть, попробовать в деле, сравнить скорости, обломался (одно доставить, другое включить) — жалко времени.
Поэтому, развитие моего проекта возможно за мой счет, на моей площадке, с привлечением накопленного опыта и знаний, пока для узкого круга заинтересованных лиц. При этом, работа возможна строго по моей технологии «управляемое внедрение», которая гарантирует мне, как заказчику, получение требуемой функциональности, к ожидаемому сроку, за приемлемую плату (проверено опытом).
Их есть у меня. Могу делиться, но на взаимовыгодной основе. Предоставлю, что выше написал, но мой проект будет еще несколько лет закрыт.
(76) AlexWhite,
Я понимаю под парсингом перевод в человекочитаемый формат. Вы хотите сказать, что в вашей системе проблема объединения решена, используя текстовые файлы «{0,{..}}»-формата? Я сильно сомневаюсь — попробуйте разрешить конфликты для таких файлов. Если не xml-формат им на замену взять, то какой?
Я ни в коем случае не навязываю свою обработку. Она тянет за собой .Net framework 4 + .Net Bridge 4. Более того, она наверняка уступает вашей по потраченному времени, а следовательно по функционалу. В моей нет, например, построения всего дерева связынных объектов метаданных, их макетов/форм/модулей. Сейчас есть разбиение по типу метаданных, а макеты/формы/модули кидаются в папку Unresolved. По скорости, думаю, моя быстрее будет, так как на Delphi довольно сложно организовать распараллеливание, а в моей сделана попытка.
В моей системе то, что не решено программно, разрешено организационно. Задача merge для v8 — очень не тривиальная, вне зависимости от того, в какой формат выгружать файлы.
Я «за» использование xml при выгрузке форм. То, что сейчас у меня выгружается в текст с фигурными скобками — издержки нынешней реализации (как просил, так было сделано, приспособились к as is). Но тексты, считаю, надо выгружать в текст, макеты в макеты, другие бинарники определенных типов в соответствующие файлы определенных типов. Без этой доработки в своем проекте вполне могу прожить и дальше, так как доработка до желаемого не решит существующих трудностей с merge для форм (xml), например. И есть еще, как минимум, одно более серьезное препятствие для merge в v8, решение которого может находиться в стороне от выбранной, в свое время, тактики — разбор cf.
Для меня сейчас производительность вторична. Отсутствие глюков сборки/разборки/взаимодействия с системами хранения версий и пр. — более приоритетно. Производительность моей терпима — cf 448Mb (КА, редактируемая с сохранением поддержки+доработки+несколько обновлений) -> разборка -> более 23тыс. файлов и папок (901 Мб) -> 6 минут. Обратно 17 минут. Вряд ли при выбранной технологии (сбор/разбор cf) можно принципиально увеличить производительность без потери качества, время сопоставимо, думаю, со штатной работой конфигуратора на сопоставимых операциях.
Итого: присоединяйтесь к закрытому проекту, с перспективой «рвануть» другой, более креативный, занимайтесь любимым делом за вознаграждение.
Или
Продолжайте работать в выбранном направлении за интерес к самостоятельным изысканиям, жертвуя свободным временем, конкурируйте с другими, аналогичными, по скорости, радуясь, что ваш проект открыт 🙂
Риторический вопрос: В чем смысл открывать проект и «рвать пупок», изыскивая собственные ресурсы — деньги (восполнимый) и время (не восполнимый), когда есть возможность, по крайней мере, зарабатывать, занимаясь интересным (любимым) делом в проекте с ограниченным (но достаточно широким) кругом допущенных лиц?
«Он сказал, не надо орден, я согласен на медаль?» 🙂
Это философский вопрос и думаю обсуждать его смысла нет, а то скатимся в пропасть.
О чем спор идет я не могу понять.
Если есть файл cf и 1с 8.3 — рассматривать альтернативный вариант имеет смысл только если сможете выгрузить в человеческий формат только измененные объекты, т.е. есть файл версий посмотрели — изменены только 3 объекта и их из cf файла и получили или же скорость в n раз больше.
p.s.: еще очень интересен разбор внешних отчетов/обработок, если cf худо бедно 1С и сама разберет/соберет, то epf файл к сожалению не сможет.
Да какой тут спор?
Если у вас есть интерес и желание, предоставлю вам возможность, подключиться к работе над моим проектом за плату (договорная). В целесообразности открытия своего проекта пока сомневаюсь.
(78) AlexWhite,
Это предложение нужно ограничить теми, кто работает с Delphi, так как ваш проект написан на нем.
Может даже лучше обратиться к аутсорсерам. Определить функциональность и принять оптимальную цену.
(79) pumbaE,
Если есть файл cf и 1с 8.3 — рассматривать альтернативный вариант имеет смысл только если сможете выгрузить в человеческий формат только измененные объекты, т.е. есть файл версий посмотрели — изменены только 3 объекта и их из cf файла и получили или же скорость в n раз больше.
Спора сейчас 2: «философский» о достоинствах и недостатках opensource-проектов и о формате выгрузки (недостатках xml).
Первый ни к чему не приведет — он вечный.
Второй конструктивный и позволит выявить истину, выслушав все доводы за и против.
Есть еще один интересный момент. Управление Торговлей 11.0.7 выгрузилась в 10598 файлов и заняло на диске 1,5Гб. Исходный cf-файл занимает 195Мбайт. Из всех файлов xml-файлов 7069 штук, которые занимают места 1,35Гб. Самые большие — роли: от 3,5 до 5 Мб каждый: 616 файлов на 1,18 Гб.
Мне кажется компании 1С не составит труда добавить такой функционал во Внешнюю обработку-Действие, раз есть функционал выгрузки всей конфигурации.
(81) Magister,
По-моему нет. Кто кроме Delphi поймет этот формат? Формат xml вы сможете обработать в любой программной платформе, в т.ч. 1С. JSON также распространен. А доморощенный формат — удел узкого круга посвященных.
(83) А сколько по времени заняла выгрузка??? загрузка??? и после загрузки проверял конфигурацию??? ошибки были???
(84) в дополнение:
Делфи значительное время тратит на компиляцию…
(85) denis_aka_wolf,
Выгрузку делал только средствами 1С 8.3. Время специально не засекал, но судя по разнице дат создания файлов выгрузка занимает 10 минут. Через свою обработку выгрузить пока не могу — не выгрузится без переделки под формат 8.3. А переделывать под сырой формат 8.3 смысла пока нет.
соответственно, я на себя, как на заказчика.
Обращался, сначала говорил, что занят (посмотрю через…месяцев), потом перестал отвечать на письма. Или мои письма попадают в спам, или он потерял интерес, такое в моей практике случается часто.
А надо бы! Сделали бы лучше, я бы у вас купил!
Поэтому, мой проект пока закрыт.
В закрытом проекте это право за вами сохраняется. Появилось желание, взялись за задачу, сдали решение, заработали. Взялись за задачу, интерес пропал до сдачи решения, сообщили «нишмагла», ни кто ни кому не должен, в чем трудность? 🙂
Мне, как потребителю, без разницы, на чем написан проект, так как от него мне нужны определенные потребительские качества. Доступ в проект предоставляю для того, чтобы сэкономить новому разработчику от года до пяти лет, написать новый может, хоть шариковой ручкой, лишь бы результат обладал требуемыми потребительскими качествами 🙂
Пройденный этап. У аутсорсеров, с кем общался, «глаза боятся» существенно сильнее, чем «руки делают» из-за отдаленности от 1С. Придать ускорение вашему или другому аналогичному проекту для меня затруднительно, если он будет хоститься где-то, вне моей RMS, так как управляемое инвестирование предпочитаю бесконтрольному 🙂
Бесплатный открытый проект может «взлететь» только при наличии у него «кровь-из-носу-заинтересованного» «толкателя» (пример GComp.exe). Когда «толкателем» выступает программист, то, проект, как минимум, обеспечен одной головой и парой рук, даже если все остальные потеряют интерес. Если я займусь обратно программированием, несколько десятков заказчиков станут несчастными, а несколько десятков специалистов потеряют работу или приработок.
Для заинтересованных, прочтите, пожалуйста, (58), свяжитесь со мной любым удобным способом. От продолжения обсуждения, извините, вынужден отказаться, дела зовут 🙂
(84)
Человек 🙂
Я предложил такой вариант как наиболее простой для автоматического слияния. С XML так просто не получится.
Впрочем, если есть альтернативы лучше — я только за 🙂
(86)
Делфи значительное время тратит на компиляцию…
Ну уж значительно поменьше, чем C/C++. Время для небольших проектов исчисляется секундами.
(88) Спасибо за развернутый ответ, вашу позицию я понял. Но пока что такой вариант работы мне неинтересен.
Ещё раз спасибо.
(89) Magister,
мой проект с ВК NativeAPI lazarus компилит не дольше одной секунды. 🙂 правда, там нет оконного интерфейса
(87) а навскидку, что там в 8.3 изменилось в структуре хранения? изменился сам формат 1с-каталога, или изменения уже внутри, в файлах конфигурации?
(91) andrewks,
Чисто визуально формат 1С-каталога не поменялся. Внутри файлов конфигурации не смотрел.
Последние доработки Elisy CfProject в версии 1.1 позволили сравняться по функциональности с v8unpack и даже превзойти эту утилиту. Теперь CfProject автоматически распаковывает image-файлы в отдельные подкаталоги. Улучшена функциональность по анализу типов и имен объектов метаданных, а также построению адекватного дерева каталогов.
Новое в Elisy.CfProject v1.1:
Распаковка image-объектов в виде подкаталога с файлами;
Распознавание имен для общих модулей, отчетов и обработок;
Переименование известных свойств согласно именам 1С;
Исправлена ошибка чтения cf-записи с нулевой длиной;
Чисто по философским вопросам:
— Я за открытую разработку и свободное распространение
— Категорически против XML
В своё время нас пытались склонить к выгрузке семёрошного .MD в xml формате, и даже в один большой файл. И я даже серьёзно рассматривал этот вопрос, прикидывал объёмы, время разборки/сборки, читабельность. В итоге, и к счастью, отказались. Читабельность победила, ну и время конечно.
+94, про читабельность
Причём, гораздо важнее даже не читабельность самих файлов, а читабельность диффов. У XML с этим гораздо хуже чем у незамысловато оформленного plain-text’а
(94) ADirks,
— Я за открытую разработку и свободное распространение
Понятно, что лучше жить вечно, чем умирать, и лучше быть здоровым, чем больным. Но реальность немного другая. Если посмотрите на проект v8unpack, то можно заметить, что он не обновлялся с 2008 года, несмотря на свободность и открытость. Вернее даже по-другому: из-за открытости и свободности компонент v8unpack не обновлялся с 2008 года. Не думаю, что кому-то было бы приятно повторить судьбу данного проекта. Чтобы его не повторить, нужно закладывать другие принципы распространения.
Теперь возьмем другой пример Snegopat. Был свободный аналог для 7.7. Но после появления платного аналога для 8.х проект начал стремительно развиваться, потому что появился стимул к развитию. Ведь сумма вырученных средств за проект — это адекватный показатель полезности и востребованности.
CfProject требует временных вложений — сейчас он нацелен на формат 8.2.14. Скорее всего в 8.2.17 изменился формат конфигурации. И однозначно в 8.3 изменился формат конфигурации. Получается, что уже известно о 2х предстоящих доработках.
Открытым проект имеет смысл делать, если есть сообщество, готовое развивать проект или для конкуренции с другим закрытым проектом. В случае с 1С специалистов по C# (CfProject написан на нем) не так уж много. Альтруистов среди нас мало — мало кто захочет учить C# только для CfProject. Да и качество кода у вновь появившихся сишарпников будет страдать. Поэтому, исходя из ваших предпочтений и реалий, напрашивается какой-то хитрый подход в лицензировании, поддерживающий баланс. Скорее всего несколько лицензий: такой подход себя оправдал в нашем другом проекте и дает ему возможность развиваться. Но сейчас говорить о лицензировании еще рано — все равно, что делить шкуру не убитого медведя. Хотя задуматься об этом надо.
(94) ADirks,(95) ADirks, (96) artbear,
По поводу формата выгрузки, не думаю, что этот вопрос принципиален. Скорее всего нужно закладывать несколько форматов. Сейчас в виде недокументированной возможности заложена выгрузка в формате XML и в формате TXT (оригинальных строках 1С). Альтернативными могут быть JSON выгрузки — достаточно быстро, думаю, реализовать, взяв парсер из другого нашего проекта. Еще альтернатива: в виде исходного кода на C# или JScript (здесь нужна реализация собственного парсера) — это более трудоемко.
(58) AlexWhite,
Расскажите о граблях более подробно, пожалуйста. Неужели такие штуки как xmldiff не спасают?