Всегда ли надо прописывать список переменных в pack?

[S.Kuskov]

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

[Maxim Gorbunov]

Цитата:

Сообщение от Владимир Максимов

Какой вариант более правильный? Почему?

Я в таких случаях пытаюсь найти похожий пример на слое SYS. В крайнем случае - на SYP. И желательно из одного из базовых модулей.

Нашёл что-то похожее в классе InventDimRenameItemDimension. Класс тоже создаётся на сервере. В диалоге тоже надо указать текстовые параметры (правда, не один, а несколько), которые не нужно сохранять в SysLastValue. Там проблема решена следующим образом:

1. В pack()/unpack() возвращается connull()/true
2. Метод canSwapBetweenCS перекрыт и возвращает false
3. Диалог строится с помощью FormRun, что, в принципе, эквивалентно forceOnClient = true при создании стандартного диалога (formRun всегда создаётся на клиенте).

То есть, в стандартном приложении используется вариант под номером 1.

P.S.: Спасибо за вопрос

[Владимир Максимов]

Цитата:

Сообщение от S.Kuskov

Смысл в формальном выполнении правил выбранного фреймворка.

Вариант 1 - это тоже "формальное выполнение правил выбранного фреймворка". Буквально. Ведь используются стандартные параметры стандартных методов этого фреймворка. Никакой "отсебятины" и "левых" методов или переменных

Цитата:

Сообщение от S.Kuskov

Коли уж наследуется от ранбейза, а он поддерживает этот самый интерфейс сериализации.

Зачем? Если в данном конкретном случае мне сериализация не нужна?

У класса RunBase очень много самых разных функций. Но ведь Вы никогда не используете их все. А только те, которые нужны в Вашей конкретной задаче

Цитата:

Сообщение от S.Kuskov

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

Т.е. Вы предлагаете мне написать свой собственный RunBase вместо перекрытия пары методов стандартного? Не слишком накладное (во всех смыслах) решение?

[Владимир Максимов]

Интересно... Похоже те, кто за заполнение pack/unpack не задавал себе вопроса "а почему, собственно?".

Почему, собственно я обязан поддерживать возможность сериализации, если она в данном конкретном случае мне не нужна?

Понятно, что ответ на этот вопрос лежит в области поддержки функционала. Т.е. если в будущем возникнет необходимость расширения и модификации данного функционала, то предполагается (!), что если класс поддерживает сериализацию, то и модифицировать его будет проще. Т.е. предполагается, что в будущем в данном функционале могут появится таки переменные, которые надо будет сохранять/восстанавливать в кеше

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

Или я не прав в своих рассуждениях? В чем ошибаюсь?

[Raven Melancholic]

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

[dech]

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

Цитата:

Сообщение от Владимир Максимов

Почему, собственно я обязан поддерживать возможность сериализации, если она в данном конкретном случае мне не нужна?

Полностью поддерживаю Владимира и задаю вопрос, зачем делать то, что абсолютно не нужно. Потому что так надо? Или потому что другие не поймут? Опять же повторюсь:

Цитата:

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

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

[DSPIC]

Цитата:

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

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

Полностью поддерживаю Владимира и задаю вопрос, зачем делать то, что абсолютно не нужно. Потому что так надо? Или потому что другие не поймут? Опять же повторюсь:

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

Ответ: Как нужно - не делайте, делайте как вам нравится. Кому будет нужно - разберется и поправит. Не заморачивайтесь.

[eugene egorov]

Цитата:

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

Ответ: Как нужно - не делайте, делайте как вам нравится. Кому будет нужно - разберется и поправит. Не заморачивайтесь.

Отличный совет. Как человек прокопавший не один десяток тыщ строк Х++ рекомендую - делайте так! И я без работы не останусь

[Владимир Максимов]

Цитата:

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

Судя по всему, обоснованные ответы, которые вы запросили вас неудовлетворяют.

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

Цитата:

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

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

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

Цитата:

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

Ответ: Как нужно - не делайте, делайте как вам нравится. Кому будет нужно - разберется и поправит. Не заморачивайтесь.

А КАК нужно-то? Точнее, не столько даже "как", сколько "почему именно ТАК"?

[DSPIC]

Цитата:

Сообщение от Владимир Максимов

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

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

А КАК нужно-то? Точнее, не столько даже "как", сколько "почему именно ТАК"?

Как нужно:
- паковать перменные в pack\unpack, использовать их в диалоге
- написать конструктор, с getLast() и перетереть сохраненные значение переменных, если предыдущее значение какой-то переменной

Обоснование
- поддержав сериализацию, вы не нарушаете правил RunBase Framework и следуете BestPractice
- класс сможет выполняться на сервере, в Batch даже если вам этого пока не нужно (может другим понадобится)
- вы полностью сохраняете универсальность класса, задавая нужное вам поведение отдельным конструктором.

Обоснуйте, почему вы "не хотите" сделать так?

[Владимир Максимов]

Цитата:

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

Обоснование
- поддержав сериализацию, вы не нарушаете правил RunBase Framework и следуете BestPractice

- Отказ от поддержки сериализации НЕ нарушает правила RunBase FrameWork. Это один их штатных, предусмотренный самим FrameWork, способ реализации
- В Best Practices я не встречал упоминания об обязательности перекрытия pack/unpack. Ну, кроме обязательности перекрытия абстрактных методов из-за чего и возникает необходимость в заглушке. Но к Best Practices это не относится

Цитата:

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

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

- Класс и так выполняется на сервере. Это было в постановке задачи. RunOn = Server
- Batch не нужен и не понадобиться. Это также было в постановке задачи

Если Batch все-таки понадобиться, то объем модификаций при использовании заглушек и при затирании кеша будет сопоставим. Надо будет организовать "вырезание" из кеша тех переменных, которые не надо сохранять от тех, которые понадобятся для работы Batch. Там придется добавлять ряд переменных именно для Batch

Цитата:

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

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

- Не понял этого тезиса. О чем идет речь?

[DSPIC]

Цитата:

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

[U]
Обоснуйте, почему вы "не хотите" сделать так?

?

[Владимир Максимов]

Цитата:

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

Обоснуйте, почему вы "не хотите" сделать так?

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

- Писать "лишний" код pack/unpack
- Инициализировать переменные, которые сразу после инициализации необходимо затирать (очищать) (getLast())

Т.е. делать "мусорную" работу. С этим можно смирится, если бы в этом был какой-то практический смысл. Но вот этого самого смысла я и не вижу

[olesh]

Я делаю так:
1. Если переменные сохранять не нужно (в теме это называется "кэш"? getLast/saveLast в общем), диалог swap-ить не нужно, batch не предусматривается - заглушки на pack/unpack.
2. Если переменные сохранять не нужно, но диалог на клиенте - реализуются полноценные pack/unpack и пустые getLast/saveLast.
3. Если переменные сохранять нужно и они совпадают с данными в диалоге - ну тут понятно.
4. Если переменные сохранять нужно, но не все, а также при swap диалога на клиента зачастую данных в нем нужно больше, чем сохранять, то в pack смотрим признак inGetSaveLast, в зависимости от него возвращаем разные версии/наборы данных. Соответственно, в unpack - обрабатываем.

Реализовывать сохранение всех данных из диалога в БД, а потом затирать, не используя, только потому, что кажется, что фреймворк такой, имхо, абсурд. В надежде, что когда-то кто-то что-то поменяет? А если нет? А сейчас все нужно реализовать, да протестировать.

ЗЫ. Ax3

[dech]

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

Плюсы в сторону первого лагеря: да, действительно, следующим программистам придется меньше материться, т.к. pack/unpack уже написаны. Остается добавить +1 в #CurrentVersion и новые поля в #CurrentList.
Все полностью соответствует BP и корректно работает.
Минус в том, что заглушка в виде лишней переменной все-таки будет в макросе #CurrentList, допустим называться она будет dummy.

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

Если ты работаешь в Microsoft, то для тебя важно, чтобы все красиво вписывалось в инфраструктуру. Но если ты пашешь на клиенте, ты в принципе можешь прикинуть, стоит ли заморачиваться и делать лишнюю работу, пусть даже в 20 строк.

[DSPIC]

Цитата:

Сообщение от Владимир Максимов

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

- Писать "лишний" код pack/unpack
- Инициализировать переменные, которые сразу после инициализации необходимо затирать (очищать) (getLast())

Т.е. делать "мусорную" работу. С этим можно смирится, если бы в этом был какой-то практический смысл. Но вот этого самого смысла я и не вижу

Я расцениваю ваше обоснование так: "не хочу". Ну так и не делайте. О всех нюансах вы в курсе, ответ/совет вам таки не нужен, как я предполагал.

Вам приходилось сдавать майкрософту ISV решения? Там куда больше спорных моментов из ряда "кому это нужно", правки занимали недели. Так принято, работа не бессмысленная и не мусорная - вам за неё платят, как минимум. Есть стандарт, принято ему следовать и не плодить антипатиерны. Еще раз - сделать можно так как вам хочется, кому нужно будет - переделает, тоже за деньги

[dech]

Цитата:

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

Если ты работаешь в Microsoft, то для тебя важно, чтобы все красиво вписывалось в инфраструктуру.

Цитата:

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

Вам приходилось сдавать майкрософту ISV решения?

Что и следовало доказать. :-)

[DSPIC]

Цитата:

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

Если ты работаешь в Microsoft, то для тебя важно, чтобы все красиво вписывалось в инфраструктуру. Но если ты пашешь на клиенте, ты в принципе можешь прикинуть, стоит ли заморачиваться и делать лишнюю работу, пусть даже в 20 строк.

Цитата:

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

Что и следовало доказать. :-)

Об этом и речь. Меньше контроля - меньше качества. На клиенте "не хочу, не буду", в MS "Надо". В итоге клиентсий код зачастую вызывает тошнотвоное чувство - уровня лабораторной работы по программированию 1-го курса института.

[Владимир Максимов]

Цитата:

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

Есть стандарт, принято ему следовать и не плодить антипатиерны.

Вот с этого места поподробнее. О каком стандарте идет речь? Я же неоднократно указывал, что то, что я делал по Варианту 1 - это тоже стандарт. Стандарт, предусмотренный самим FrameWork. Просто этот подход используется нечасто из-за его не типичности (нестандартности самого подхода, а не реализации)

Ради интереса, сделайте поиск по перекрытым методам pack/unpack. Заглушки в этих методах встречаются довольно часто в разных стандартных классах. Но! Все они имеют RunOn = calledFrom, при этом неявно предполагая, что речь будет всегда идти о запуске на стороне клиента. Т.е. нет проблемы сериализации.

Просто в данном конкретном случае "камнем преткновения" является RunOn = Server. Это как раз и есть то самое "бессмысленное и беспощадное" требование клиента, которое я вынужден сделать. Клиента не интересует надо/не надо. У него есть свой "стандарт"

Вариант 1, описанный мной - это следование требованию клиента об установке RunOn = Server, но при этом выполняется отказ от сериализации. Еще раз подчеркиваю, отказ происходит стандартными способами, предусмотренными самим FrameWork

-------------

Ответ на какой вопрос я хотел услышать, но так и не услышал

Чем грозит отказ от сериализации при настройке RunOn = Server? Т.е. класс запускается на сервере, а форма диалога на клиенте без создания дубликатов. Происходит прямое "общение" формы на клиенте и обслуживающего его класса на сервере.

[Maxim Gorbunov]

Ещё вот такой аргумент пришёл в голову: меньше всего ошибок в коде, который не надо писать. Ну или другими словами, чем меньше вы кода напишете, тем меньше вероятность того, что в нём будет ошибка. Применительно к данному случаю: в пустых pack() и unpack() меньше шансов поймать ошибку, чем если их полностью реализовывать. Я думаю, многие здесь сталкивались с ошибкой, когда типы данных в контейнере в SysLastValue не соответствовали тому, что ожидал получить unpack() (да, я знаю про CurrentVersion). Зачем лишний раз подставляться, если это не нужно для решения задачи?