But to be honest, I've started doing stuff a little more manually, at least for rest endpoints. I like to have full control in one place.

I've standardized on Gson for some cases involving dates, unfound enums, collections, and ad hoc maps. I've also done this type of configuration in multiple places (ex a rest serializer, some GSON code in a JMS bean, etc)

I'm using javax.json since it comes with JavaEE, but I added some Kotlin extension functions to make it easier to work with.

But for me, the testing is key. I use Ready API and have a lot of tests built out for myself and for clients

Here's a question I've been pondering all day. Its a bit hard to describe but here goes: I have a need to present different models using various visual components, (

textfield

,

slider

etc). To start with only the basic components are needed, but it is likely that more advanced compositions will be needed later on. The problem is that I don't know what the models will contain so I can't create views or view-models for them before hand - it is the creator of the components (i.e. the boxes I've show in screenshots) that decides what data he or she wants to store and how to display it. My current idea is to use some sort of meta-language to describe the models and based on that dynamically create the view for each model. Has either of you done something like this?

Maybe build a generic ViewModel based on a Map of properties rather than specific fields?

Yes, that is also an idea. I could "cheat" a bit using `is`to determine the property type and select the correct view-component

For the more complicated views I'll probably require the creator of the components to actually create the view and view model based on a defined interface that I simply display in a pre-determined area of the application

In the View, use a class "ViewBuilder" to add Nodes to the View. ViewBuilder supplements the Node type with enough information to bind to the ViewModel. Ex, an added TextField would have an ID which would be a key into a Map-based structure in the ViewModel. As always, the View Nodes bind to the ViewModel for updates.

After a Node is added or removed to this ViewBuilder on-demand, the View / ViewModel bindings are recomputed

I think you could write a sophisticated enough expression with an ObservableMap filled with StringProperty and other objects. If not, you could write an update() method in the View that listens to a ViewModel change via the EventBus. In this update() method, you'd pull ViewModel values from a Map into your View Nodes through iteration.

hm, good ideas, @carlw

I need to do some experimenting

@permalmberg I think TornadoFX can support this case pretty easily. You're basically making the typical Type Safe Builder into a procedural statement (the add / remove node operation) and hooking it up to a loosely-typed structure: Map<String, Property<?>>

where the String key is an ID that can match what you're user is generating for the Node

@carlw Yes, now that you put it like that... Maybe I've been overthinking it

@User uploaded a file: API and Supporting ViewModel for Nodes On Demand and commented: @permalmberg I'd start with classes like this, then come up with a recomputeBindings() method that's called after the adds / removes take place

@carlw yeah, that seems like a good start. Not bad at all actually

@edvin This reminds me of the old Struts 1 DynaBean...Maybe there's a use for a DynamicViewModel that would build itself from the View. The value would be in the commit/rollback and in issuing calls to a Model component.

@carlw I'm too tired to do this tonight though, way too long day at work. Hoping for an easier one tomorrow, can't wait to get started with this. Many thanks for your input

np

@permalmberg I do something similar for our Task system. It's currently being rewritten to TornadoFX, I'll see if I can present my approach in a meaningful way 🙂

@edvin Oh, that'd be awesome.

can never steal enough ideas 😮

@permalmberg Can you share a typical object that you'd present like this? @carlw Ah, yes, the DynaBean approach 🙂 We could probably autogenerate an UI based on ViewModels perhaps? We'd need some metadata on the properties as well though. The thing is, for most use cases, using builders is already so pleasant so you don't need this IMO. Once the data is dynamic, this approach might fall through anyway. Depends on the data and dynamics of it I guess.

@edvin I wouldn't do this for all apps...I'm dealing with a bunch of production issues today caused by misinterpretations of a flexible data structure

@edvin right now t'd be something like this in its most basic form

class { 
var mqttBroker: String by property("localhost") 
var mqttBrokerPort: String by property(1883) 
}

@carlw I hear you 🙂 There are the occasional use case though.

@permalmberg There is nothing dynamic here, so this UI could be generated automatically pretty easy, right?

@edvin Well, "dynamic" as in I don't know beforehand what properties the model will contain and if the user prefers to use text field or a slider to display the value etc...