Hierarchical UI

[ah]

Hi Alan,

I have been going through Kernel.js. I am quite interested.

Can you please advice on the following?

What is your recommendation on how a hierarchical UI (not all modules are on the same level) be implemented using Kernel.j?

Example:

Project > Tab 1 > Box 1

 Box 2

 Box 3

Project > Tab 2 > Tab 2.1 > Box 5

     Box 6

Should tab area be a module?

Should each tab have a hub?

Any code sample/example?

Regards / AH 

[alindsay55661]

Ah,

This is an excellent question. Note that Kernel doesn't recommend one way or another when it comes to rendering. So the short answer is that you can divide your app into as many modules as you like. But this doesn't provide any coding guidance or examples. At the moment I can't provide that for you (time constraints) but I can at least tell you how I am handling it.

I typically start by extending Kernel with a rendering engine of some sort. Usually this engine allows me to easily render modules inside of other modules. Keep in mind though, this can give the impression that modules rendered inside other modules are somehow able to communicate with each directly or belong to each other in some way. That is not the case. This is purely a function of rendering, not module relationship. As far as the app is concerned these modules know nothing of each other.

A second approach I take is to implement my own tabbing mechanism where the tabs are a module and each "page" is a module. This works well because I can fire off an event on tab click and the listening module can bring itself to the front  when it hears the event. This tends to be more flexible than using a canned tab widget because you can now easily add other listeners to the tabs.

Really I have been somewhat silent on this issue because I wanted to stay out of the scene when it comes to your rendering implementation. However, I can see the benefit of having an example renderer that addresses these questions. I can tell you that one is coming, but that it won't be anytime soon. In the meantime you can play around with setting up your own.

Regards,

Alan

[ah]

Hi Alan,

Thank you for the response. Much appreciate it.

I wanted to go with the second approach. Unfortunately, this approach necessitates that all modules (Tab1 Modules + Tab 2 Modules + Tab 2.1 Modules) be registered and started (so that it can listen to the tab click) irrespective of whether the user would need the tab or not. This is where I think it wouldn't be a good idea (there will be too many modules). May be I am missing something here!?

Regards / AH

[alindsay55661]

Well, unless you are dynamically loading your modules they are already in the client so I am not sure what you mean by "too many". I typically build my apps into a single app.js file that includes all the modules and I usually start them all on load. I manage their display and interaction through listeners and events. This works quite well but isn't necessary. It all depends on how you structure your modules and your app. In some cases you may wish to start and stop them on the fly. I have found that merely showing and hiding them is slightly more flexible and easier to manage because they continue to listen for events in the background and can respond accordingly. 

Either way, the footprint for started modules vs. stopped modules is next to nothing. The only difference is that the global listener object will store an extra pointer to your module methods. So you don't need to worry, you already have all the modules in memory, stopping them doesn't save you much.

Hope this helps.

Alan

[ah]

Hi Alan,

I get your point.

My case was each tab qualifies to be an app on its own, which is why I felt that static loading may be too resource intensive.  

I guess either building each tab as an app or one single app with dynamic loading of modules are the way forward. 

Regards / AH