|
Унификация параметра (разные формы, разные параметры)
|
|||
---|---|---|---|
#18+
Есть приложение, работающее. Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25.
У каждой кнопки свои параметры, все пихается в строку - текст прямиком, списки - индекс и так далее. Например, смотрите фото: Кнопка 1: параметр в виде : "1;0" - индекс в списке и ложь Кнопка 2: параметр в виде : "1" - индекс в списке Кнопка 3: параметр в виде : "0;9,99" - ложь и сумма Кнопка 1 имеет действие "Nakinut" Кнопка 2 имеет действие "Zakinut" Кнопка 3 имеет действие "Prikinutsa" Вопрос: Как отойти от этой порочной системы и сделать пару Name + ToDo в виде класса, чтобы было без разницы сколько параметров и сколько кнопок.... Спасибо. Нужно в итоге подктнуть для JSON: На выходе хочу: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Параметры param1, param2 ... в идеале должны иметь реальные названия (например название контролла). Какие есть варианты реализации такой структуры? Параметры всегда стринг. Нечто вроде: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Большое спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
29.11.2021, 23:28 |
|
Унификация параметра (разные формы, разные параметры)
|
|||
---|---|---|---|
#18+
bzums, JSON, XML, ... ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2021, 00:01 |
|
Унификация параметра (разные формы, разные параметры)
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2021, 00:22 |
|
Унификация параметра (разные формы, разные параметры)
|
|||
---|---|---|---|
#18+
bzums Как отойти от этой порочной системы Для начала - спросить "у заказчика есть вот такая задача, как её правильно решить", а не "у меня есть крутой бред, как сделать его более навороченным". ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2021, 06:22 |
|
Унификация параметра (разные формы, разные параметры)
|
|||
---|---|---|---|
#18+
Спасибо. Вопрос был в том, каким образом реализовать класс параметра. Сейчас он в виде текста и длина его разная для каждой формы. К тому же он не содержит название параметра. То есть для формы1 параметр1(два значения) Для формы2 параметр 2 ( одно значение) Но при этом его объявить один раз как некий общий .... Через Set of ? Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2021, 07:57 |
|
Унификация параметра (разные формы, разные параметры)
|
|||
---|---|---|---|
#18+
Зачем вообще нужны эти классы и параметры ? Вы храните "описание" формы в базе ? Почему бы не просто хранить DFM ? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2021, 08:17 |
|
Унификация параметра (разные формы, разные параметры)
|
|||
---|---|---|---|
#18+
bzums Спасибо. Вопрос был в том, каким образом реализовать класс параметра. Сейчас он в виде текста и длина его разная для каждой формы. К тому же он не содержит название параметра. То есть для формы1 параметр1(два значения) Для формы2 параметр 2 ( одно значение) Но при этом его объявить один раз как некий общий .... Через Set of ? Спасибо. Какой смысл в общении в форме монологов? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2021, 08:41 |
|
Унификация параметра (разные формы, разные параметры)
|
|||
---|---|---|---|
#18+
bzums, для начала почитать темы: атрибуты, использование rtti потом посмотреть модуль Rest.JsonReflect ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2021, 09:36 |
|
Унификация параметра (разные формы, разные параметры)
|
|||
---|---|---|---|
#18+
Почитать про модель MVC Model-View-Controller Перестать привязывать сущности предметной области к формам и кнопкам. То что ты называешь "кнопка" это или вызов редактирования объекта или команда с параметрами. Пишется слой классов (Model, она же модель предметной области) и команд (доменная, бизнес логика) с параметрами , а формы - это средства визуального доступа к ним (View). Model не должа знать о View Хранение модели может быть организовано разными способами (XML, JSON, INI, БД). За хранение отвечают сами классы модели или или отдлеьная сущность (ридер-райтер). Код сохранения может быть написан явно в классах или через RTTI, зависит от требуемой скорости работы и устойчивости модели к измененниям. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2021, 10:45 |
|
Унификация параметра (разные формы, разные параметры)
|
|||
---|---|---|---|
#18+
Использовать не строковые, а типизированные поля классов. К строкам можно приводить для внешнего универсального доступа к классам. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2021, 11:12 |
|
Унификация параметра (разные формы, разные параметры)
|
|||
---|---|---|---|
#18+
Спасибо. Извиняюсь за несвоевременный ответ. Формально да, описание формы хранится в базе в строковом формате, разделитель - точка с зарятой. Если говорить о данном решении - имеет наверное право на жизнь. Решение не мое. Моя задача - прочитать из базы и выдать json. С этим тоде нет проблем. Если говорить о формате: "50;100;150;200;MS Sans........" - я имею описание и знаю, что Left = 50, Right = 100 .... Font = "Ms Sans" и так далее. Все прекрасно до тех пор, пока среди этих параметров не попался один - сборный (разделитель - ":"), по смыслу это состояние контролов - либо текст из мемо, либо индекс из списка и так далее. Внимание!!! :-) проблема в том, что форм этих 100 разных видов, разное количество контролов. Пропарсить не проблема и выдать в виде: параметр1:"лвамваотт" параметр2:"отслвос" параметр3:"укащлзщлук" Самое интересное когда надо дать им осмысленные имена. Для одной формы это будет: ПротянутьРуку:"лвамваотт" КакуюРуку:"мвам" Для другой ПослатьПодальше:"отслвос" Длительность:"укащлзщлук" Это ставит в ступор. Что, просить к каждой форме дописать массив с вариантами значений? Самому сделать некий стандартный класс и и по текщему состоянию (не говорю про то, что будет дальше) самому сформировать эти названия? Второе как мне кажется правильнее. Вопрос в том, как сделать так, чтобы не переделывать. Придумал сделать через запись, количество полей для каждой формы будет разное. Типа так: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39.
Но как-то кудряво получается... Хотитк верьте, хотите - нет, но этот код реальный ( не мой): Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25.
... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2021, 12:21 |
|
Унификация параметра (разные формы, разные параметры)
|
|||
---|---|---|---|
#18+
bzums, А ты уверен что твоя задача вообще решаема в общем виде? У тебя там, по ходу, набор частных случаев, а на каждой форме свой собственный разбор параметров. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2021, 12:24 |
|
Унификация параметра (разные формы, разные параметры)
|
|||
---|---|---|---|
#18+
Нет, не уверен. Поэтому и написал тут (крик о помощи). Этот текстовый парметер создается в каждой форме ( и стандартно ) - перебираются все контроллы по пордяку и все. ЧТо если добавить и втрой параметр, но не текст а: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Ну или каким-то стандартным образом а не TParameterForma1.... TParameterForma100 Спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2021, 12:45 |
|
Унификация параметра (разные формы, разные параметры)
|
|||
---|---|---|---|
#18+
Привести всё в удобночитаемый вид и не парится. Хранить в базе DFM. 100 форм не так уж и много. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2021, 12:52 |
|
Унификация параметра (разные формы, разные параметры)
|
|||
---|---|---|---|
#18+
Ну вот это как раз и идет в разрез с перечнем требований, где первым пунктом указано, что формат (возможно в целях совместимости) должен остаться как есть... Описание же можно попросить реализовать (даже и в каждой форме) Но вот выкатить некое унифицированное описание / класс было бы правильнее... СПаибо. Буду думать. Тем не менее, буду признателен за идеи. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2021, 13:08 |
|
Унификация параметра (разные формы, разные параметры)
|
|||
---|---|---|---|
#18+
Тяжело пробираться через ваш сленг. Почему бы в базовом классе не сделать метод Код: pascal 1.
а потом в наследниках реализовать этот метод так, как нужно конкретному классу? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2021, 13:23 |
|
Унификация параметра (разные формы, разные параметры)
|
|||
---|---|---|---|
#18+
_Vasilisk_, Именно так и реализовано сечас - у каждой формы есть метод GetSettings(const settings: string) И это вполне себе ничего, так кака у всех них один единый параметр строкового типа. Получил - записал в базу. До тех пока мне не понадобилось добавить также и имена (а не только значения). Ломать это нельзя, поэтому все еще в поиске нормального рещения ,если оно существует конечно. Идеально решенение - некий вспомогательный класс (параллелльно) этой фукции, который бы знал и названия и значения. Т.е. хотелось бы иметь единственный параметр (например record), но его наполнение было бы при этом разным для каждой формы. Возможно такое и не реализвать.. Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2021, 14:16 |
|
Унификация параметра (разные формы, разные параметры)
|
|||
---|---|---|---|
#18+
bzums _Vasilisk_, Именно так и реализовано сечас - у каждой формы есть метод GetSettings(const settings: string) И это вполне себе ничего, так кака у всех них один единый параметр строкового типа. Получил - записал в базу. До тех пока мне не понадобилось добавить также и имена (а не только значения). Ломать это нельзя, поэтому все еще в поиске нормального рещения ,если оно существует конечно. Существует конечно. Систему хранения менять не надо. bzums Идеально решенение - некий вспомогательный класс (параллелльно) этой фукции, который бы знал и названия и значения. 1. Не один класс, а классов, сколько есть сущностей с разными параметрами, в соответствии с предметной областью. (возможно с использованием наследования и агрегирования). Параметры типизированные. Называется объектная модель, модель предметной области. Никаких тут строковых параметров для чисел / перечислимых типов. 2. У каждого класса метод записи - чтения в базу, формирующие строку в соответствии с принятым форматом. 3. Формы редактирования знают о классах, которые редактируют, у них есть метод забрать / обновить поля объекта. Попытки убрать этот копеечный бойлерплейт ("обобщить" с помощью каких то соглашений об именовании и RTTI) ведет с излишней сложности и хрупкости системы к изменениям. Пусть изменения структуры объектов контролирует компилятор. 4. Если нужен доступ к свойствам объекта в формате параметр - значение , это реализовается в виде отдельных оберточных методов, не имеющих отношения ни к хранению в БД, и к формам редактирования. Либо специальными методами, либо RTTI. Преобразование значения параметра в строку делается в этих методах. имена параметров тут могут не совпадать с именами полей объекта, могут быть русскими bzums Т.е. хотелось бы иметь единственный параметр (например record), но его наполнение было бы при этом разным для каждой формы. Возможно такое и не реализвать.. Спасибо. Такое не надо ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2021, 15:03 |
|
Унификация параметра (разные формы, разные параметры)
|
|||
---|---|---|---|
#18+
bzums _Vasilisk_, Именно так и реализовано сечас - у каждой формы есть метод GetSettings(const settings: string) И это вполне себе ничего, так кака у всех них один единый параметр строкового типа. Получил - записал в базу. До тех пока мне не понадобилось добавить также и имена (а не только значения). Ломать это нельзя, поэтому все еще в поиске нормального рещения ,если оно существует конечно. Фактически, у Вас параметры определяются номером в тексте с разделителями. Если нельзя ломать - дополните именами: procedure GetSettings(const settings:sring;const Names:string='') Там где нужно, передавайте вторую строку, где каждому параметру из settings соответствует имя. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2021, 15:06 |
|
|
start [/forum/topic.php?fid=58&msg=40116056&tid=2036825]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
28ms |
get topic data: |
8ms |
get forum data: |
3ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
others: | 12ms |
total: | 127ms |
0 / 0 |