Correct way to bypass cumbersome MVC logic

[Tuoman]

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!

[Martin KJELDSEN · Accepted solution]

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]

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

[Martin KJELDSEN]

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!

[HP]

+1 on the ping, if possible :)

That tool sounds like it is just what I need!

[MKsen.1]

+1

[JHarding]

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]

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]

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