ax3,ax4,ax2009,ax2012: Есть ли красивый способ передать packable объект между клиентом и сервером?

[mazzy]

вопрос по ax3,ax4,ax2009,ax2012

предположим, у нас есть объект с правильно реализованным интерфейсом SysPackable (есть правильные pack/unpack)

Сейчас, чтобы передать объект с клиента на сервер и обратно, приходится подпрыгивать с методами newOnServer, newOnClient, вручную проверять ObjectOnServer, вызывать pack/unpack и прочие некрасивости.

Есть ли красивый способ передать packable объект между клиентом и сервером?

[belugin]

Вынести подпрыгивания в свой статический метод?

public static client SysPackable copyToServer(SysPackable _object)
{      
      return MyCoolClass::createOnSever(getClassID(_object), object.pack())
}
private static server SysPackable createOnServer(ClassID _classID, container _packed)
{
      SysPackable ret = new SysDictClass(_classID).makeObject();
      if (!ret.unpack(_packed))
      {
            throw error(Error:wrongUseOfFunction(funcname());
      }
      return ret;
}

[gl00mie]

Цитата:

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

предположим, у нас есть объект с правильно реализованным интерфейсом SysPackable (есть правильные pack/unpack)
Сейчас, чтобы передать объект с клиента на сервер и обратно, приходится подпрыгивать с методами newOnServer, newOnClient, вручную проверять ObjectOnServer, вызывать pack/unpack и прочие некрасивости.

А зачем это все внезапно может понадобиться для чего-либо, кроме наследников RunBase, где всё это уже и так реализовано? Что за сценарий использования, если не секрет?

[mazzy]

Цитата:

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

RunBase, где всё это уже и так реализовано?

Что именно "все" уже реализовано в RunBase?

Цитата:

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

Что за сценарий использования, если не секрет?

Как изменится ответ на исходный вопрос?

[gl00mie]

Цитата:

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

Что именно "все" уже реализовано в RunBase?

Вот это вот всё:

Цитата:

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

Сейчас, чтобы передать объект с клиента на сервер и обратно, приходится подпрыгивать с методами newOnServer, newOnClient, вручную проверять ObjectOnServer, вызывать pack/unpack и прочие некрасивости.

В RunBase уже есть запуск на сервере, переключение на клиента, вызовы pack/unpack и даже подсказка, вызываются ли они внутри диалога или нет.

Цитата:

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

Цитата:

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

Что за сценарий использования, если не секрет?

Как изменится ответ на исходный вопрос?

Я начну издалека Есть целый ряд людей, которые задают очень и очень общие вопросы или весьма "широко" формулируют задачу, имея в виду весьма конкретный частный случай. Этим любят заниматься и разработчики, и консультанты, и пользователи. Но когда начинаешь задавать уточняющие вопросы, часто оказывается, что их частный случай, который они имеют в виду, формулируя общую проблему, имеет с этой формулировкой не так уж много общего.
Таким образом, ответ на исходный вопрос может кардинально отличаться в зависимости от того, о какой конкретной задаче исходно идет речь. Банально, потому что постановка задачи

Цитата:

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

красивый способ передать packable объект между клиентом и сервером

в моем понимании очень отличается от постановки задачи

Цитата:

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

передать объект с клиента на сервер и обратно

Я, к примеру, не понимаю сходу, зачем один и тот же packable объект передавать обратно с сервера на клиента, если это что-то, выходящее за рамки возможностей, уже реализованных в RunBase. Импортированный файл передать на сервер и потом обратно или что? И если надо все же передавать данные в обе стороны, то точно ли это будет один и тот же packable объект?

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

[mazzy]

Цитата:

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

В RunBase уже есть запуск на сервере, переключение на клиента, вызовы pack/unpack и даже подсказка, вызываются ли они внутри диалога или нет.

Ну, и как это делается?

Цитата:

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

Я начну издалека

ответ?
достал чаёк, щас буду наслаждаться профессиональным ответом по делу.

Цитата:

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

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

а... опять бухтение. что ж, поддержу настрой.

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

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

Цитата:

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

Я, к примеру, не понимаю сходу, зачем один и тот же packable объект передавать обратно с сервера на клиента

(шепотом)я тоже не понимаю
(шепотом заговорщика)расскажи где ты это увидел?
(нормальным голосом)
можно рассказать как передавать разные packable объекты
а также можно рассказать о других способах
а поговорить о красоте этих способов.

при особом желании, можно поговорить не только о классических версиях аксапты, но и о современных, в которых остался только сервер, но вопрос сериализации объектов по прежнему актуален.

Цитата:

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

то точно ли это будет один и тот же packable объект?

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

Цитата:

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

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

Как сценарий использования повлияет на ответ о красивом способе?
Если у тебя есть несколько кардинально разных способов, то озвучь их.
Есть ли красивый способ, работающий во всех случаях?

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

[EVGL]

"The beauty is in the eye of the beholder"
Вы задали вопрос, на который принципиально нет удовлетворяющего всех ответа. Теория алгоритмов, к примеру, не оперирует понятиями красоты, а понятиями разрешимости и трудоемкости.
Так что пафос неуместен.

[ax_mct]

Цитата:

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

вопрос по ax3,ax4,ax2009,ax2012

предположим, у нас есть объект с правильно реализованным интерфейсом SysPackable (есть правильные pack/unpack)

Сейчас, чтобы передать объект с клиента на сервер и обратно, приходится подпрыгивать с методами newOnServer, newOnClient, вручную проверять ObjectOnServer, вызывать pack/unpack и прочие некрасивости.

Есть ли красивый способ передать packable объект между клиентом и сервером?

Все же у любого зрелого программиста есть восприятие вторичных программистских признаков.
Здесь я не соглашусь с консультантами для которых это всего лишь побочное ремесло

Красиво это xSysLastValue::saveLast(this) и xSysLastValue::getLast().
Страшная такая но суровая красота

[belugin]

Цитата:

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

зачем один и тот же packable объект передавать обратно с сервера на клиента, если это что-то, выходящее за рамки возможностей, уже реализованных в RunBase.

1. Например, мы его где-то сохранили. Не как SysLastValue а в другой таблице (например что-то типа настроек печати).
2. Это может быть не тот же самый клиент (типа у нас чатик или алерты какие-нибудь)

Если рассматривать связанные вопросы, мне нравится и одновременно не нравится как сделано в SysOperation framework - там можно разметить свойства класса атрибутами и они сохраняются по именам - при добавлении и удалении свойств надо меньше париться версионированием.

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


Красота́ — эстетическая (неутилитарная, непрактическая) категория, обозначающая совершенство, гармоничное сочетание аспектов объекта, при котором последний вызывает у наблюдателя эстетическое наслаждение. Красота является одной из важнейших категорий культуры. Противоположностью красоты является безобразие

[belugin]

Возможно Маззи практикует Ax-буддизм и это коаны:

Ученик, получивший коан от мастера, пытается решить коан всеми возможными способами и «подключает» все больше и больше сил для решения логически неразрешимой проблемы. В результате, когда «отключаются» все пять чувств, ученик находится на стадии, которую в йоге именуют дхарана. В этом состоянии коан и ученик остаются один на один (плюс некоторое блуждание ума). Если ум ученика достаточно «зрелый», то однажды блуждания ума затихают и остается лишь коан. В этот момент коан и ученик — целое, ученик испытывает проблеск реальности, известный как просветление или сатори.

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

[mazzy]

Цитата:

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

Ученик, получивший коан от мастера...Хлопок одной ладонью, клиентский код в пакетном задании, передача объекта туда где он уже есть (обратно на клиента).

Как странно ты воспринимаешь реальность. Ну, ок.

Цитата:

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

Все же у любого зрелого программиста есть восприятие вторичных программистских признаков.

У зрелого есть не только восприятие, но и способность задавать вопросы.

Всем,
Меня искренне прикалывает, как вместо обсуждения технического вопроса, участники пытаются обсуждать автора вопроса.
Повторюсь, что давным-давно этим страдали 1Сники.
https://coub.com/view/1s5rp

Цитата:

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

Красиво это xSysLastValue::saveLast(this) и xSysLastValue::getLast(). Страшная такая но суровая красота

Согласен, что такой способ есть.
Но чтобы красиво использовать SaleLast c this, нужно переопределить четыре метода (или предоставить четыре параметра).
SaveLast записывает данные в контейнер, следовательно никаких индексов по содержимому. А также ограничение на размер сохраняемых данных (сложности с передачей больших контейнеров).

SaveLast записывает контейнер с данными как одно memo-поле, которое в SQL не пришей кобыле хвост. А можно записывать каждое значение контейнера как отдельную запись в SQL, все записи одного SaveLAst должны получить некий идентификатор сессии. Так можно получить поиск по содержимому.

это что касается SaveLast.
Возвращаясь к теме передачи объекта между клиентом и сервером...

Как уже упоминал некий ax_mct ранее, можно записывать данные в отдельную таблицу. Можно ли запись в отдельную таблицу сделать более элегантной, нежели четыре метода для SaveLast?

Можно разбивать packable контейнер на куски. Чтобы обойти ограничение на размер и уменьшить относительные накладные расходы на обслуживание клиент-серверного пакета. Можно пообсуждать за минимизацию относительного оверхеда.

Я удивлен, но не увидел обсуждения стандартных классов по передаче файлов между клиентом и сервером SysFileDeploy, AifWebReferenceUtil (второй умеет как с клиента на сервер, так и с сервера на клиент). Отлично понимаю, что способ передачи файла - не идеал. Но красоту поискать можно. Можно и посравнивать с другими способами.



как способ взаимодействия между клиентАМИ и серверАМИ можно рассмотреть запись в AOT\resource.

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

может еще есть какие способы?
а какой из них самый красивый? в том смысле, что нравится вам?

=================
А да, и mazzy обсуждать тоже можно, и о том что runbase уже есть, как и о принципиально-философской неразрешимости данного технического вопроса.
Это прикольно.

[axm2017]

Цитата:

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

..У зрелого есть не только восприятие, но и способность задавать вопросы.
.

Ок. Так чем вас не устраивает стандарт в виде RunBase и ко?

[mazzy]

Цитата:

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

Ок. Так чем вас не устраивает стандарт в виде RunBase и ко?

почему вы считаете, что он меня не устраивает?

[axm2017]

Цитата:

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

почему вы считаете, что он меня не устраивает?

Если устраивает то и вопроса по сути нет. Работайте с ним он есть во всех версиях и стандартен.

[mazzy]

Цитата:

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

Если устраивает то и вопроса по сути нет. Работайте с ним он есть во всех версиях и стандартен.

Есть, сэр! Разрешите продолжать работу с ним?

Для тех, кто знает, что передача объекта между клиентом и сервером может быть вне "сценария" пользователь запустил некую обработку
и понимает различие между использованием понятия и самим понятием, повторю вопрос:

Цитата:

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

вопрос по ax3,ax4,ax2009,ax2012

предположим, у нас есть объект с правильно реализованным интерфейсом SysPackable (есть правильные pack/unpack)

Сейчас, чтобы передать объект с клиента на сервер и обратно, приходится подпрыгивать с методами newOnServer, newOnClient, вручную проверять ObjectOnServer, вызывать pack/unpack и прочие некрасивости.

Есть ли красивый способ передать packable объект между клиентом и сервером?

[gl00mie]

Цитата:

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

чтобы красиво использовать SaleLast c this, нужно переопределить четыре метода (или предоставить четыре параметра).

В исходной постановке ведь говорится про объект packable, а не про this - для packable можно сделать вспомогательный класс, который будет реализовывать нужные методы SysSaveable, а на вход получать некий идентификатор плюс SysPackable-объект, который уже собственно паковать либо распаковывать вместо себя. Не знаю, правда, насколько такая реализация будет считаться "красивой".

Цитата:

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

SaveLast записывает данные в контейнер, следовательно никаких индексов по содержимому. А также ограничение на размер сохраняемых данных (сложности с передачей больших контейнеров).
SaveLast записывает контейнер с данными как одно memo-поле, которое в SQL не пришей кобыле хвост. А можно записывать каждое значение контейнера как отдельную запись в SQL, все записи одного SaveLAst должны получить некий идентификатор сессии. Так можно получить поиск по содержимому.

Ну вот, начали с клиент-серверной передачи объектов, а пришли к поиску по содержимому объектов в базе SQL Напомнило один анекдот:

Цитата:

- Слушай, ты разработчик. Ответь, почему разработчики всегда неправильно оценивают время на создание программ?
- Представь что тебе надо разгрузить машину, сколько времени это займет?
- Пару часов
- Это камаз
- 8 часов
- Камаз, груженый песком
- 12 часов
- У тебя нет лопаты и инструментов, только твои руки
- 2 дня
- На улице -40
- 4 дня
- Камаз вообще под водой
- Так же нечестно, ты постоянно придумываешь новые условия! К чему ты мне вообще все это рассказываешь? Вы, разработчики, вечно всякую фигню рассказываете! Вместо этого могли бы просто оценить правильное время на разработку.

Цитата:

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

Я удивлен, но не увидел обсуждения стандартных классов по передаче файлов между клиентом и сервером SysFileDeploy

У меня лично был весьма негативный опыт его использования

Цитата:

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

AifWebReferenceUtil (второй умеет как с клиента на сервер, так и с сервера на клиент).

А он точно был в версиях "ax3,ax4", которые упоминаются в исходном вопросе?

Цитата:

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

как способ взаимодействия между клиентАМИ и серверАМИ можно рассмотреть запись в AOT\resource.

Это те ресурсы, которых не было в старых версиях, а в ax2012 они - свои на каждом АОСе с его локальным CIL, да? И вообще, писать в приложение (design-time) что-либо для каждодневной работы конкретной инсталляции (runtime) - это моветон, как по мне. Тем более в последних версиях и не осуществимый.

Цитата:

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

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

Т.е. в одном случае предлагается резать контейнер на части, чтобы обойти ограничение на размер пакета в ax4/ax2009/ax2012, а в другом случае предлагается просто закрыть глазки ладошками и представить, что этих ограничений нет? Пускай, мол, среда времени выполнения абстрагирует нас на вставке в кэш на другой стороне от того, что есть какие-то там RPC и какие-то там maxbuffersize в настройках...

Цитата:

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

Отлично понимаю, что способ передачи файла - не идеал. Но красоту поискать можно. Можно и посравнивать с другими способами.

Такое ощущение, что вместо решения практической задачи идет составление опросника для собеседования. Как там у Джоэла Спольски?

Цитата:

Каким бы превосходным C++ кодировщиком ни был человек без опыта в API, он знает только около 10% того, что он должен использовать каждый день для написания кода запускаемого на API. Когда дела в экономике идут хорошо, это не имеет значения. Вы все еще имеете работу и наниматели платят стоимость вашего обучения соответствующей платформе. Но когда в экономике царит неразбериха и 600 человек подают заявления на каждую открытую вакансию, наниматели могут позволить себе удовольствие выбирать программистов которые уже эксперты в интересующей их области. Например, программистов, которые могут назвать четыре способа заслать файл по FPT из кода на Visual Basic и слабые и сильные стороны каждого из них.

[mazzy]

Цитата:

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

В исходной постановке ведь говорится про объект packable, а не про this

правильно говоришь. про SysLastValue заговорил ax_mct
совершенно верно, в исходной формулировке не было.

Цитата:

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

- для packable можно сделать вспомогательный класс, который будет реализовывать нужные методы SysSaveable, а на вход получать некий идентификатор плюс SysPackable-объект, который уже собственно паковать либо распаковывать вместо себя.

а распаковщик откуда узнает этот идентификатор? распаковщик на другой стороне.
раз уж все равно передавать надо между клиентом и сервером, то может лучше передавать не идентификатор, а сам объект?

Цитата:

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

Не знаю, правда, насколько такая реализация будет считаться "красивой".

Я тоже.

Цитата:

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

Ну вот, начали с клиент-серверной передачи объектов, а пришли к поиску по содержимому объектов в базе SQL Напомнило один анекдот:

gl00mie, даю маячок: про SysLastValue заговорил ax_mct.
мой исходный вопрос повторить?

Цитата:

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

У меня лично был весьма негативный опыт его использования

это не значит, что подход, примененный в этом классе нельзя рассматривать для решения исходного вопроса.

Цитата:

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

А он точно был в версиях "ax3,ax4", которые упоминаются в исходном вопросе?

нет. это не значит, что подход, примененный в этом классе нельзя рассматривать для решения исходного вопроса.

Цитата:

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

Это те ресурсы, которых не было в старых версиях, а в ax2012 они - свои на каждом АОСе с его локальным CIL, да?

ага. но они могут быть синхронизированы. почему бы не рассмотреть и этот вариант и отметить плюсы и минусы.

Цитата:

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

И вообще, писать в приложение (design-time) что-либо для каждодневной работы конкретной инсталляции (runtime) - это моветон, как по мне. Тем более в последних версиях и не осуществимый.

отличное рассуждение в ветке про "красивый способ".
майкрософту бы в уши.

Цитата:

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

Т.е. в одном случае предлагается резать контейнер на части, чтобы обойти ограничение на размер пакета в ax4/ax2009/ax2012, а в другом случае предлагается просто закрыть глазки ладошками и представить, что этих ограничений нет? Пускай, мол, среда времени выполнения абстрагирует нас на вставке в кэш на другой стороне от того, что есть какие-то там RPC и какие-то там maxbuffersize в настройках...

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

Цитата:

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

Такое ощущение, что вместо решения практической задачи

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

Цитата:

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

идет составление опросника для собеседования. Как там у Джоэла Спольски?

господи... с составлением опросника у меня тоже проблем нет.

[mazzy]

Цитата:

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

предположим, у нас есть объект с правильно реализованным интерфейсом SysPackable (есть правильные pack/unpack)

И еще.

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

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

[belugin]

Есть еще статический метод create. Если его реалзовать, то можно класть объекты в стандартные коллекции и паковать и распаковывать их (т.е. не надо будет передавать явно идентификатор класса, как я сделал в первом своем сообщении в этой ветке).

[mazzy]

Цитата:

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

Есть еще статический метод create. Если его реалзовать, то можно класть объекты в стандартные коллекции и паковать и распаковывать их (т.е. не надо будет передавать явно идентификатор класса, как я сделал в первом своем сообщении в этой ветке).

как в одной фразе уживаются "есть" и "если его реализовать"
1. есть в стандартных коллекциях map, list, set
2. есть хлипкое соглашение, что если реализовать статический метод, который принимает контейнер, то он должен действовать как create в стандартных коллекциях.
3. соглашение является хлипким, поскольку даже классы sys слоя нарушают это соглашение

да, я видел твое первое сообщение.
да, ничего на него не ответил, поскольку еще в исходном написал:

Цитата:

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

Сейчас, чтобы передать объект с клиента на сервер и обратно, приходится подпрыгивать с методами newOnServer, newOnClient, вручную проверять ObjectOnServer, вызывать pack/unpack и прочие некрасивости.

Есть ли красивый способ передать packable объект между клиентом и сервером?