https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • b
    where as if you had "MagicTable extends ScrollView" then you can pull it bits (copy paste) from tableview as you want
  • b
    Yeah, that's a very good idea.
  • b
    but you get all the scrolling and virtualisation features anyway
  • b
    Alright, thanks for the discussion. 🙂
  • b
    no worries, lemme know if you decide to give it a go and if i can help in any way 🙂
  • b
    If they bug me more about doing the stuff they want for the app. I'm half inclined to completely rewrite it. 😄
  • b
    whats the app?
  • b
    Handling customer orders. Very hard coded DB.
  • b
    Basically each order (root level item) has basic order data, then rows of "items to search", each that has "items found" and each that has "distributor found" with price and such.
  • b
    gotcha
  • b
    So there's 3 levels of hierarchy. I made it for my parent's firm. They've been using google spreadsheet, but it was starting to be slow for them with 50k+ rows.
  • b
    On top of that basic UI there's realtime multiuser editing, smart fulltext search and smart hinting based on context (like hinting item found for specific item searched, if certain order parameters fit).
  • b
    right
  • b
    its the MagicTable that i think its the main part that will take time, the rest seems like app sugar... and if the table is working the rest sounds like it might just fall into place
  • b
    the more i think about it, the more im sure that a scrollview with a specialized "virtual layout" will do exactly what you want
  • b
    wont be simple though, ofc, but i think all the bits are available to make it work
  • b
    Yeah, it was like that. Once I had that working, the rest of UI was mostly a breeze.
  • b
    The other big part of the app was the multiuser editing and DB syncing and a few stupid decisions along the way.
  • b
    Like not realizing backups need to be realtime until production. 😄
  • b
    🙂
  • b
    dont you just lock the record when its being edited?
  • b
    There's only single DB on the server, so there's no need for locking.
  • b
    But it had to handle syncing the local data on each client, and their actions.
  • b
    Stuff like someone editing a row while another user adding new row, then deleting a row, then undoing all that.
  • b
    oh, so the client has a cache of the data?
  • b
    Just what's visible, or well, loaded.
  • b
    All changes are then synced in real-time.
  • b
    right, yeah... i get it... you are looking at record A, someone else changes record A, you want to see an updated record A
  • b
    It felt simple, but the syncing ended up being quite a pain when I started adding undo-redo.
  • b
    no doubt
1...135136137...1687Latest