Inheritance Guidelines at the Top of the Food Chain

[Q7]

I've been toying around with the AF and have run into a conundrum:

I have a Parent class: CONTROL from which my GUIs inherit. CONTROL holds the queues for the GUIs and also for the loops running the MODEL. I am calling the MODEL the main VIs that perform I/O operations, heat, cool, get motor speed, etc...

My problem is this: The GUIs need to typecast Actor into CONTROL class to send messages to the MODEL. CONTROL needs to run its own Actor Core as it mediates the GUIs and the MODEL mediators to some extent. The GUIs also each have an Actor Core but since they inherit their class from CONTROL, their Actor Core has CONTROL Actor Core inside it. I don't want CONTROL to be running in each GUI, it has it's own place seperate from GUI. The only solution I can think of is to make another child class of CONTROL which becomes "CONTROL Mediator" or something. However, now I have to up-cast "CONTROL Mediator" to access the queues for the MODEL & GUIs. In fact, when I launch the MODELs from CONTROL Mediator, I have to send their Queues to CONTROL and not CONTROL Mediator, Then somehow get those Queues to the instance of CONTROL running in the GUI as well. Wow, it's gonna take a genuis to decode what I just wrote...

To summarize:

I want a CONTROL class that holds the MODEL and GUI queues and also has it's own Actor Core. I want all my GUI classes to inherit from that class without each GUI Actor Core having the CONTROL Actor Core inside it. I just want the Actor.lvclass actor core in them.

I am new to all this, LVOOP included so if this question is fundamentally flawed please point me at the proper lessons!

[AristosQueue (NI)]

It's not going to take a genius because this is well trod ground. What you're working on is a Model-View-Controller architecture. Wikipedia has a good explanation of that pattern. We've had a few people build this with the AF, though no examples are yet posted on the forums... getting closer, but not ready yet. But the consensus that is emerging is that the setup looks like this:

1. your top-level Application Actor launches three independent actors: Model, Controller and (optionally) View.

2. Application sends four messages...

1. gives Model's queue to Controller
2. give Controller's queue to Model
3. give View's queue to Controller
4. give Controller's queue to View

2. Controller's job is to broker information between Model and View and make the information sent from Model to View as simple as possible. View displays values that come from Controller and exposes controls that do nothing more than toggle raw property values and sending the new property values to the Controller. When View doesn't exist, Controller may be running its own algorithms to tell the Model to do things. Commonly, Controller includes history information about the model to support operations like Undo and Redo if necessary.

3. Controllers are intimately aware of the type of model, but model knows nothing of the controller. Similarly, views are intimately aware of the type of controller, but know nothing of the underlying model. How much the controller knows about the View is a matter of debate -- sometimes they are tightly coupled, sometimes not.

4. View's Actor Core is the one that actually opens its front panel.

5. Views may be shut down and new Views started without stopping the Controller or the Model. Controllers typically have the same lifetime as the model. In at least one variation, the Controller is responsible for launching the Model instead of the Model being launched independently.

That's a quick summary. Variations on this architecture have worked very well in two projects I know of, but none that are postable to the forums (yet). You may work out your own variation on this theme. Eventually, we'll get a cannonical setup, but not yet.

[Q7]

Thank you for the summary, this is what I have more or less. I was looking for a way to have the View as a child of the Control so that the View could sent messages directly to the Model. View still gets commands only from the Control and the Control routes messages from the Model to View and Model to Model. Control would also launch Models and Views as required so Control is all the top-level application would need to launch. Otherwise I have to launch a View Mediator and Model Mediator which basically do nothing but pass commands from Model or View to Control. I figured why have 3 "mediators" when one will do just fine. I suppose that's like your setup #5.

My guess is you would say if I want to do it that way, fine, but the View should not be able to send a message directly to the model...I want it to! The best way I can think to do that is to have the View be a child of the Control so it can inherit the Model's queues. Then both Control and View can send identical messages to the Model. But, I cannot do that because Control has an Actor Core and so does each View. I don't want to run Control's Actor Core inside of every View I lauch, I just want access to Control's cluster so I can use "Control to Model" messages without sending through Control.

It sounds like a worse idea than it really is...I think

[AristosQueue (NI)]

You're free to share the queues around as much as you want... if giving the model's queue to the view makes sense in your application, go ahead. That limits your flexibility and it usually leads to someone writing features that only the UI can trigger and inevitably someone wants programmatic control, but that may be a tradeoff you're willing to make.

[Q7]

Actually, I wanted the view and the control to have access to the queues simultaneously. Too late anyway, I realized, once I started busting out Do.vis, just how easy it is to route the message through the control. It will be great having all my messages in the project tree as opposed to the case structure. KUDOS for that alone. 

Why don't you have NI make up a few thousand t-shirts that say nothing on them but: Do.vi

(that's a freebee, I'm an XL &/or L, btw)