@alexp11223 It wasn't renamed.

setOnAction

is default for JavaFX, but we recently added

action

as a shortcut. It hasn't been released yet, but we updated the guide perhaps a bit prematurely 🙂

I'm thinking about adding a feature that will let a View intercept the back/forward button actions from the Workspace. This can be used to either veto the navigation or doing something else entirely. Right now I need it because I have a View with a TabPane and inside one of the tabs you can navigate to another View (using replaceWith). I want the back button to show the previous View inside the TabPane, but not affect navigation.

and can it navigate between tabs?

Sure, you'll get a callback when the back button is clicked, so you can return false to have the Workspace essentially do nothing. Then you can do whatever you want instead.

Thinking about these functions inside UIComponent:

@User uploaded a file: Untitled

The implementation inside the Workspace back button would be pretty easy:

@User uploaded a file: Workspace back button action

Committed, it seems to be working good, so I'll update the guide as well.

Described in the guide.

@edvin - sounds like the kind of functionality that would be useful in a wizard as well?

@gtnarg Yeah, the wizard will need something similar. Either NetBeans RCP or Eclipse RCP got Wizards pretty right if I'm not mistaken, so we might look there when we create our own.

we look there for inspiration you mean?

@edvin sent you a pull request because of the

config

helper let me know if it is any good what I did there🙈

@ron Yes 🙂

@nimakro Sweet, will check it out tonight!

@edvin Don't say sweet to fast you might not like it 😉

@User uploaded a file:

Mr. Bean style transport!

@nimakro I took a peek now. Is

orElse

really "Kotlin"? It feels more like Java 8.

?:

usually is preferred in Kotlin, so I don't think we need those really. They are just more ways to say the same. While looking at this I got an other idea. Every Component already has a

config

object, so what if the

App

class also got one, and you could easily access the

config

object of other Components? Then you could use the

App

class's config object as a global config store, without needing a Context. Inside a Component,

config

would always point to the current config, and you could access other classes config object via something like

config<MyApp>

or something. I haven't thought this through yet, just got the idea while reading.

I also think the relationship between

configBasePath

and

configPath

is a little confusing.

Maybe we just need configPath, but it could be configurable?

@edvin Your right I am actually form a Java8 background, I also realized after the commit that kotlin has the

?:

... Yeah I don't mind if we get rid of the Context... I would agree that the

configBasePath

and

configPath

vals are not the best, the idea was to allow to customize the target file but can't change it more then once... we could also get rid of

configBasePath

and just have every

component

specify there own path if needed.

Nah, forget I said that about configBasePath and configPath, that's fine.

I think we can keep the general concept of configBasePath and configPath but just make it easier to understand.

It's good to be able to say for example that the app's config should be in /etc/myapp/conf.

So that makes sense.

Yeah the idea was to allow for the app's config /etc/myapp/conf and for the components /etc/myapp/conf/component or the could be in two totally separate dirs.

OK, so if any component, including the app class, can dictate either a relative or absolute config path, and there is an easy way to ask for the config of any component, I think we have a flexible solution.

I will experiment a little with json properties also, we have support for it, I just never used it.