Model GUI Mediator When to Use Mediators and when not
lazarus / 21-General

----------------------------------------------------------------------
Weitentaaal · 2023-11-22 15:05

Hello,

i know the Basics of Simple Mediators for TCombobox and TEdit and so
on. But i don't know about coloring and enable/disable Controls. For
Example an Edit.
If the Value you input is not a Valid number between 1-10 then i want
the edit to be in a red color if it is between 5-10 i want it to have
an orange Color.

Same goes with enabe and disable. if i want to disable a Button for
example because a variable in my model has a certain value.

How do i do that? do i write Mediators or just use a Simple observer ?
i don't want to do work that could have been avoided, thats why i ask
this question.

thanks for any Hint/Idea whatever.

----------------------------------------------------------------------
sfeinst · 2023-11-22 16:31

Just my 2 cents

I have found when trying to decide between 2 options, if one is
correct, it will be obvious.  When a choice is not obvious, it usually
doesn't matter.  Pick one and go with it.

When it comes to design patterns, I usually think of it as a a tool to
communicate between a designer and a programmer.  A common language. 
Designer wants a mediator here for this purpose.  Programmer, ok, I
might have gone with a simple observer but hey I'm not the designer. 
I don't consider patterns to be a list of do this in all of these
circumstances.  Just a way to communicate your decision.  Art vs
science.

When it comes to object-oriented, you will never be able to avoid
doing work you could have avoided.  It's in its nature to offer too
many ways of doing the same thing and then the community changing its
mind on what is considered the "best" way.  You will always look back
and say, I shold have done it this way.

So, don't look for our choice.  Just pick one you like to code and go
with it.

----------------------------------------------------------------------
Weitentaaal · 2023-11-23 06:33

Quote from: sfeinst on November 22, 2023, 05:31:01 pmJust my 2 cents

I have found when trying to decide between 2 options, if one is
correct, it will be obvious.  When a choice is not obvious, it usually
doesn't matter.  Pick one and go with it.

When it comes to design patterns, I usually think of it as a a tool to
communicate between a designer and a programmer.  A common language. 
Designer wants a mediator here for this purpose.  Programmer, ok, I
might have gone with a simple observer but hey I'm not the designer. 
I don't consider patterns to be a list of do this in all of these
circumstances.  Just a way to communicate your decision.  Art vs
science.

When it comes to object-oriented, you will never be able to avoid
doing work you could have avoided.  It's in its nature to offer too
many ways of doing the same thing and then the community changing its
mind on what is considered the "best" way.  You will always look back
and say, I shold have done it this way.

So, don't look for our choice.  Just pick one you like to code and go
with it.

Thanks, that was a relief for my mind, just wanted to create that
perfect code for my other teammates that will or might use it in the
future. I will keep that in mind since my thoughts are always like
"the way i try to do this seems wrong" so i start to overthink to
much.