@Ruckus: absolutely! I will make sure to demo just that.

Sweet!

I need a name for the counterpart of

ViewProvider

. The provider will offer up it's View to anyone interested. I was thinking about

ViewConsumer

as the receiver. The

ViewConsumer

will receive the View from the provider if it is registered for the correct discriminator. Is

ViewConsumer

OK?

if you make that a viewconsumer should the viewprovided not be a viewproducer?

I will try to avoid the need for implementing this interface though, it will just be an anonymous function on the call site.

@ron: Right, that makes more sense. But it might give the wrong idea. A ViewProducer simply contains info about the class of a view, so it doesn't really produce it. Don't know if that's problematic.

I also have

ApplicationProvider

and

ViewProvider

by now.

Maybe

Producer

is a better word for all of them.

hmmz in general a producer makes, a provider provides and does not necesarilly have to make (it can provide an already created object)

Then Provider makes more sense.

how about receiver instead of consumer

(going back to my chicken on the bbq)

Grind I have slack on the phone too

@ron: Perfect, I'll go with that. Thanks! (Haha, just thought about it, I even wrote

receive

above when I tried to explain the functionality)

I was thinking that

EventTarget.addChildIfPossible

could support creating a Tab for the given child node if

this is TabPane

, something like this:

@User uploaded a file: Untitled

Then you can do

tabPane += someNode

. I can also use this for auto-embedding Views in TabPanes.

Of course, the View could listen to onDock and change the title of the root's parent Node if it wants to.

It's also possible to listen to

ViewProvider

services and add Views from them manually. That way you have more control over what you do with the provided View. You could for example open a modal for the View, or add it to any kind of Node in any way you like.

This is sounding pretty amazing

I also moved

Node.removeFromParent

to

EventTarget.removeFromParent

so that a Tab can unregister from it's

TabPane

.

@Ruckus: I really hope I can get this to work :))

I imagine you could also add a list of them to a menu that would let you open them as a modal when selected. A menu of add-ons if you will.

Oh yes, absolutely 🙂 Nice one.

That's easy to do already by implementing ViewReceiver.

I just need a nice name for the function that takes a Node, and makes sure ViewProviders are presented to it so it can decide if the Views in the ViewProviders should be added to that Node. Hm.. that was hard to explain..

It looks like this now. The description and name is a bit clunky:

@User uploaded a file: Untitled

I can't think of better wording