Аксапта и динамический код?

[mazzy]

Цитата:

Изначально опубликовано EVGL
Так или иначе, но работы на неделю найдется.

Вот и я про то.
Программировать не надо!

[SnowMan]

Цитата:

Изначально опубликовано mazzy

Вот и я про то.
Программировать не надо!

а кто говорит, про программирование? Мы так... с бубном танцуем, лишь бы бизнес дышал...

Цитата:

Изначально опубликовано mazzy

А предложенный SnowMan'ом механизм делает создание справки вообще нереальным делом.

с созданием справок еще не разбирался (согласен с EVGL, что справка последнее дело)... но я подозреваю, что нельзя в системе создать справку для динамически создаваемой объекта (формы), каковым является диалог... или я не прав и можно для диалога, создаваемого в коде, определить справку?

Цитата:

Изначально опубликовано EVGL

Но: вы вызываете приложения и на клиенте, и на сервере. Тогда вы просто ОБЯЗАНЫ сериализовать класс с помощью методов pack() и unpack(), иначе все параметры "потеряются" по дороге.

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

Цитата:

Изначально опубликовано EVGL

Аргументы. Полагаю, вы вводите аргументы строками? Жуткий геморрой с преобразованием типов. Как минимум - десятки проверок на предмет того, что значение введено в правильном формате. А если еще связаться с расширенными типами данных в качестве параметров...

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

Цитата:

Изначально опубликовано EVGL

Направление на похожий механизм: конфигуратор продукции. Отличный образец. Делает совсем не то, что вам нужно, но с аналогичным интерфейсом.

Как ответил мне наш внедренец на вопрос где посмотреть данный механизм - у вас куплена не вся функциональность, и он не доступен...
странно, неужели он требует лицензирования?

[mazzy]

Цитата:

Изначально опубликовано SnowMan
но я подозреваю, что нельзя в системе создать справку для динамически создаваемой объекта (формы), каковым является диалог... или я не прав и можно для диалога, создаваемого в коде, определить справку?

В 2.5 нельзя.
В 3.0 можно, но это непросто.

[Антон Солдатов]

Цитата:

Изначально опубликовано mazzy

А ведь точно нет. таблица SysLastValue. Я не помню где читал об этом механизме. Поищите в каталоге technical info. После прочтения документа разобраться с этим механизмом очень даже несложно.

наверное в Базе Знаний форума Эта статья мне очень даже помогла. Толковый материал. Спасибо Максиму.
http://www.axforum.info/forums/showt...s=&threadid=30.

и вот это обсуждение
http://www.axforum.info/forums/showt...=&threadid=888

[mazzy]

Цитата:

Изначально опубликовано Антон Солдатов
наверное в Базе Знаний форума Эта статья мне очень даже помогла. Толковый материал. Спасибо Максиму.

Наверное. Максиму Спасибо.

[Волчара]

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

Да программированием можно действительно решить все проблемы. Но решать их можно по разному. Программирование сверху без вникания иногда может потребовать перелопачивания большого количества форм, для решения малых проблем. Программирование при хорошем знании системы позволяет изменением одного базового метода изменить работу системы в целом.

Молодые специалисты довольно быстро осваивают Х++ и Morph Х. Они действительно довольно просты. Освоить работу основных классов гораздо труднее.

Хочу напомнить старый анекдот
10 баксов за то что ударил кувалдой
а 990 за то что знал куда

[SnowMan]

Цитата:

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

Скажите Волчара, Ваше сообщение по теме обсуждения или просто мнение на тему "не надо изобретать велосипед"?

Если вы подскажите мне стандартную функциональность для задачи, описанной мной в http://www.axforum.info/forums/showt...9676#post19676 я с радостью выброшу свой проект и буду копать в указанном направлении...

[mazzy]

SnowMan, вы поставили не задачу. Вы просите подсказать как правильно использовать инструмент, который вы хотите использовать.

На самом деле, часть задачи вы описали, где то выше. Там была часть про то, что вам зачем то надо открываьт внешние приложения. Хочу обратить внимание, это тоже НЕ задача. Это способ ее решения.


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

[SnowMan]

Считаю, что на данном этапе аксапта не является системой самодостаточной и способной охватить весь бизнес компании целиком...
Исходя из этого всегда будет необходимость осуществления взаимосвязи системы, построенной на основе аксапты и сторонних приложений...
Отсюда и задача: "Создание механизма управления сторонними приложениями..."
Чем вам не задача?

Цитата:

Изначально опубликовано mazzy
мне кажется, что вы просто ушли не в те дебри. Поэтому у вас такие проблемы на каждом шагу.

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

Цитата:

Изначально опубликовано mazzy
Но то, что никто свои задачи подобным вашему образом не решал - повод задуматься.

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

[mazzy]

Цитата:

Изначально опубликовано SnowMan
Считаю, что на данном этапе аксапта не является системой самодостаточной и способной охватить весь бизнес компании целиком...
Исходя из этого всегда будет необходимость осуществления взаимосвязи системы, построенной на основе аксапты и сторонних приложений...
Отсюда и задача: "Создание механизма управления сторонними приложениями..."
Чем вам не задача?

Чем не подходит OLE Automation? Что вы подразумеваете под "управлением"?

Цитата:

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

Почему вы думаете, что "универсальный" механизм будет эффективнее статически написанного кода? Чем отличается ваша универсальность, от среды разработки? Ведь среда разрабоки это и есть самая универсальный механизм.

Цитата:

Изначально опубликовано SnowMan
без нелюбимого вами программирования
[/B]

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

Сугубое ИМХО: Когда речь идет о создании более универсальных механизмов, нежели сама среда разработки, с большой вероятностью можно утверждать, что говорящий просто не знает что нужно делать.

[SnowMan]

Цитата:

Изначально опубликовано mazzy
Чем не подходит OLE Automation? Что вы подразумеваете под "управлением"?

Он действительно не подходит, так как не всякая внешняя задача поддерживает этот механизм, например, программа созданная еще для DOS и прекрасно справляющаяся со своими задачами лет так уж 5 или коммандный файл (cmd, bat) и т.п.

Цитата:

Изначально опубликовано mazzy
Почему вы думаете, что "универсальный" механизм будет эффективнее статически написанного кода? Чем отличается ваша универсальность, от среды разработки? Ведь среда разрабоки это и есть самая универсальный механизм.
Сугубое ИМХО: Когда речь идет о создании более универсальных механизмов, нежели сама среда разработки, с большой вероятностью можно утверждать, что говорящий просто не знает что нужно делать.

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

Цитата:

Изначально опубликовано mazzy
На самом деле программировать я люблю.

Никто не сомневается

Сугубое ИМХО: Ветка перерождается во флейм... Думаю, надо остановится