but then, I'm still not sure how to implement it in a nice generic way ....

this is what i do with javafx. in some cases, there are separate JARs used that just take commonly-shared events and general data structures

because the nice thing about the dependency injection via scope is, that my main view has no knowledge of what data he is actually dealing with

hes just receiving some data, in a scope and then creates some view he really doesn't know anything further about - well not entirely true: I require all of these do be an instance of an abstract AppTab class ....

but other than that, the main view is just the mediator, just caring about how that new thing is added to its tabpane

so the problem comes in, when I wnat this different behavior with the already-opened tab

So assume I'm the mainview, and I just received some fancy Event that carries some data, telling me I should possibly do some opening stuff with it. Then I realize, that that the kind of tab it wants me to open is one of the "CanAppendTo" style tabs, and I also know, that I already have one of these opened somewhere

how do I pass my data to it?

hmm ... I could probably just pass the scope around?

(So yeah, I was lying a bit - the main view does know a few things now. for instance, it has a way to tell, what tab type it already has opened.)

i would just fire the events and let whoever is handling the events decide if something is open or could be appendedto

the key thing to decouple is to not have one part of the program building a screen for another part of the program...that's view-level coupling. a factory or even a builder is fine from a code reuse standpoint, but that's not the pattern here

yeah, you're totally right, thanks for pointing out that issue - It seemed like a fitting idea in that situation, but I already felt bad while I did that ^^

At least things in my code are encapsulated well enough that changing this the way you suggest should be a no-brainer, I just need to remove one find call in one place, change the type carried by the event a bit, and put the find inside the subscruption.

So the path on that question is very clear to me. What initially really puzzled me most, is the other question of how to pass parameters 2 times to that view in a different way - but this also gets a little bit easier.

So I think I will go by just making an

Appendable

interface that has a Method

append(scope: Scope)

then the main view checks for that interface, and if it is implemented by the tab type to be opened, it does the distinction.

if it doesn't have a tab open already, it fill find<> one with a scope which is carried by the Event

if it dies have one, then it will pass the scope carried to the

append

method. 🙂

post some code. i think we can get something going within a screen or two. cover the various scenarios of a totally standalone new window or something that relies on program state like a selected item (ex, a project file)

ok - just fixing a bit of code, then Ill see if I can get extract the essence of it 🙂

OH, I see that FXEvent carries a scope already - what is it for? may I use that one maybe? xD or would that be abuse?

or is it even meant to do exactly what I mean to do?

Ok - @carlw - the way I can imagine it right now, a way to get rid of the view-coupeling in a way that allows me to remove the dependency would be to have a Data-Object that is unique to the View, such that the MainView knows, which View to find by associating ... but that isn't really what you're going for i guess....

So for now, I will implement it in a way that let's the Main view do the View-instancing and works, but doesn't actually get rid of the coupling - then I will boil that down to a minimal rubnning example and post it here. Not sure if I can get that done tonight however.

since its past midnight already here 😉

oh no,

Component.subscribe

to a

MyEvent: FXEvent

does not work when

MySpecificEvent : MyEvent

is fired 😢

@iari this is similar to something I'm doing with pure javafx in a large app maintained by a team of 3-7 developers. the open window event can be thrown from anywhere. a central dispatcher receives it and decides what to do. for a view, it creates (if needed) and shows a window. for a fragment, it creates (always needed) and shows a window there can be multiple fragments but only a single view view parameters are shared through CDI. fragment parameters are passed. however, there is a global fragment CDI variable that can be used depending on the poster

Thanks for sharing this @carlw - you are awesome! So I see the way your decouple the view in the end it the

windowid

String - it allows for the

ViewAndFragsDemoView

to not know the view classes directly, but open them just via

fire(OpenWindowEvent("view", ""))

as in Line 54. Right now, the way I have it is very similar to what you posted except for one part: I do not have the string, but reference the View Classes directly (so I do still have the View coupling), the plain reason being, that I really enjoy the TypeSafety of the curretn solution ...

hopefully you got enough use for the task at hand. I also use a self-registering scheme based on annotations (javafx). In terms of a separation of concerns, the window (view, fragment) is the best source for identification info. sometimes you might not want to compile against the view classes.