https://kotlinlang.org logo
Join Slack
Powered by
Wrapped all TreeItems on a `NodePrinter` (I'm horr...
# tornadofx
v
Wrapped all TreeItems on a 
NodePrinter
(I'm horrible naming things) that either use toString or a custom 
(T) -> String
function. For some items I override that callback to print the version property, others that are plain string with the image I let the TreeView print them with the graphic and text
Copy code
class NodePrinter<T>(val node: T, val callback: (T) -> String = { it.toString()}){

    override fun toString(): String {
        return callback(node)
    }
}
d
I am personally not a fan of mixing a display name with the toString method. ToString shall be the representation of the object for the programmer for logging or uargh-debugging purposes. I'd prefer a "displayName" property on those objects for that matter. And happy to see you resolved your issue! Thanks for sharing your thoughts
v
In this case is more than just a displayName actually, I need to switch which property to display
its more a stringconverter than anything else
so depending on the TreeItem Type, I use a different function. Could use a method called displayName() for sure and again rely on old toString for simple types for simplicity
But the problem is that if I go the route without toString it won't work
because the moment I use
Copy code
cellFormat {
text = nodePrinter.displayName()
}
The images will stop showing. I could not find a way (not without a lot of effort at least) to mix text and graphic depending on the item being processed
I found an answer here: https://stackoverflow.com/questions/46207822/tornadofx-treeview-cell-factory-not-being-called but seems a hell of work for such thing
Another thing I'm still struggling with JavaFX/Tornado is how to really decouple my domain objects from the view/model I'm still not clear on the whole ViewMode ItemViewModel concept from the docs.
Most my domain objects are really simple POJOs mapped as data classes from either database or REST access.
Do I map those to a ViewModel/ItemViewModel, because I would really like to avoid having SimpleStringProperties on my domain objects, and having to create another object to have them and the view model, now I have 3 types to represent a domain entity 😞
d
Depends what you want and how much abstraction you need. You know "Clean architecture" from Uncle Bob? You could have at GUI level your gui models whilst in the core your real domain objects are sitting and from layer to layer you can use a transformater .. there is a nice book about this topic "Getting your hands dirty with clean architecture" 🙂 <If you do not want SimpleStringProperties in your Domain i get it - which means it is important to you that your Domain is decoupled from the specific GUI framework you are using. And that the nice part of clean design, database, gui, everything are external factors which should be easily exchangeable. In order not to get messed up during coding i think handling the layers with gradle projects is a nice approach - only the gui layer can then access javafx-properties so you can during compile time be safe .. but long topic and really depends if you think this piece of software will be there in 10 years or not.
and in the end - nothing beats simplicity .. clean architecture is quite a big chunk of work.
I mean all you'd do would be a mapping from domain to gui-domain in hope you'll need it someday when you'd change the gui framework, right?
v
Thanks for the input, in the end I think I may just be overthinking this. Having my view model be just a representation of domain object elsewhere is not that bad. Also made piece with those that come from a database, for now the app I'm building ship with its own H2 database, its not as I will need those objects anywhere else.
Again, thanks for all the help
Having a lot of fun learning more about javafx and tornado. I was already giving up on UI and java. I'm glad we have a lightway alternative to electron 😄 and one that does not require you to write javascript
d
oh man yes! i personally couldnt stand javascript. Typescript okay, maybe. But UI with kotlin and tornadofx is just really nice
out of curiosity - why did you need a embedded db for your application? i had this thought as well - but for now i will go with just a normal tree datastructure .. but for now i have just one view where all data sits
v
There's no real reason besides the fact that I'm way more familiar with SQL. I may need to do some more complex queries. H2 is a phenomenal DB, performance is amazing for a single client. I prefer it to sqlite to be honest. One problem I'm having is that if my app crashes (happens quite often in development) my db can get locked, as the file lock is not released, this is a bit of pain.
Another thing I like about H2, because its just SQL I'm using flyway for db migration for example, so on start I create all tables and insert base entities. In a real app, when a new version gets released I can count on flyway to perform table schema updates, find deltas and such. neat feature
Open in Slack
PreviousNext
Powered by