Skip to main content
Tuoman
Tuoman
Senior II
May 6, 2020
Solved

Correct way to bypass cumbersome MVC logic

  • May 6, 2020
  • 3 replies
  • 1937 views

Hello,

I have a container that is present in every single view (namely a header that contains a clock).

I need this header to read 12h/24h time setting, and then draw time accordingly.

If I use Model-View-Controller, I must implement activate() method in every single Presenter to load this setting from Model, and implement "setTimeSetting()" in every single View, which will call the container "setTimeSetting()". This is a bit overkill, isn't it?

So instead of that, I just implement the function in FrontendApplication, and call it in the container only using application().getTimeSetting().

Is it appropriate to store a global variable in FrontendApplication instead, that the container reads directly? Am I missing something here, is there going to be problems with that?

To me, this seems to be easier approach in most cases, and less risk of typing errors when making lots of function calls between M-V-C objects.

Thanks!

This topic has been closed for replies.
Best answer by Martin KJELDSEN

Search this forum for how to create a BaseView shared across views. I also wrote a small application that does it. I'm coming up with a tool that can do this because it requires modifying the generated files since the Designer does not support it yet - It will.

It is by far the best implementation.

/Martin

3 replies

Martin KJELDSEN
Martin KJELDSENBest answer
Principal III
May 6, 2020

Search this forum for how to create a BaseView shared across views. I also wrote a small application that does it. I'm coming up with a tool that can do this because it requires modifying the generated files since the Designer does not support it yet - It will.

It is by far the best implementation.

/Martin

Tuoman
TuomanAuthor
Senior II
May 6, 2020

Thank you, sounds like ideal solution. I probably will just wait for new TouchGFX release before implementing this, we have time.

Martin KJELDSEN
Martin KJELDSEN
Principal III
May 6, 2020

I'll try to remember to ping you when my tool is done - I think it'll integrate nicely with the designer, actually, using the "post generate command" in the .touchgfx project file, to patch up some generated header files. I'll prove it!

JHarding
JHarding
Senior
May 8, 2020

Curious on a time frame for this, we are just getting into heavy development, and this could save us inordinate amounts of time.

Martin KJELDSEN
Martin KJELDSEN
Principal III
May 11, 2020

Okay, i'll make an effort to get a first version out shortly then. I'm thinking i will come up with a naming scheme that will indicate to the tool which views to group together. And then you could either create the baseview directly inside the designer (helpful) or do it by hand.

/Martin

Martin KJELDSEN
Martin KJELDSEN
Principal III
May 11, 2020

I'll just do a broad-cast here to get some input:

What would you like to see from such a tool? As stated above - My initial idea was to simply use a naming scheme to classify views as belonging to group X. E.g. maybe i would create the following views:

  • LoginMainView
  • LoginInfoView
  • LoginTaskBar

If i were to run the tool now it would detect that more than 1 view had the prefix "Login", but no base-view existed yet. Maybe it would create it or suggest that it be created. IF LoginBaseView existed, it would modify the above classes accordingly to inherit from such a baseview as well as some other modifications.

So, you could say this tool would be a sort of MVP Validator. Maybe it coudl be extended to handle general signals to each "group" as well. There are many possibilities, while we get this implemented in the designer.

/Martin

/Martin

Terms & ConditionsAccessibility statement