https://linen.dev logo
Powered by
# haxe-ui
  • f
    not much because you would still use getProperty
  • b
    yeah, exactly, so it would just be "i think there is a someOtherString property"... ... "no, there isnt, ok"
  • f
    right
  • b
    and realistically, it wouldnt care before that because in order for the item renderer to care about it, there would also have to be a component in the renderer called "someOtherString"
  • b
    OK, thats sorted in latest haxeui-core, you dont have to use @:isVar now
  • f
    cool it works
  • b
    nice find 👍
  • f
    cheers
  • f
    now I can rid of IItemTransformer and type my data correctly
  • b
    yeah, i think the IItemTransformer is ill concieved... at best it should be a little more "hidden", i think its valid to want to be able to use 
    ArrayDataSource<String>
    and things "just work"... but a) i feel like this is already handled somewhere else (will have to check) and b) as you have found out the naming / location of it makes you think "right, gotta transform my data", when it should have happened automatically and was a bug
  • b
    that said, i do think there is scope / use for some type of simple transformation system (which is clearly what the current implementation is) it just needs to be thought out a little more
  • b
    that was written years and years ago, and my best guess is i went "that'll work" without putting too much thought into it 🙂
  • f
    the idea of some transformer is valid because with data-sources you always have the need to transform the physical representation to a viewable representation. But maybe it would be better to have this per field basis, because you want to represent some type of fields in a consistent way. For example a float could be represented as currency and another as temperature. Currently I would (and do) use an approach per data source, but maybe there is more elegant way.
  • b
    yeah, i agree 100%, the concept of transforming "raw" data into "presentation" data is perfectly valid... i just think that current transformation wasnt thinking about that at all
  • b
    it was literally just "lets turn int -> { text: "1"}"
  • b
    so i defo will add something, but something a little more "fit for purpose" and not an after thought as IItemTransformer seems to be
  • f
    that worked to some degree but is a lot of boiler plate code - maybe something like map fields [a,b,c] to currency field representation and [d,e] to temperature field representation. If there is no transformation for some field than a default transformation is used ( = toString, toBool etc.).
  • b
    exactly, something more "real world useful", but currently its bottom of the list as, ideally, ill get a new release out this weeked 🤞
  • f
    great - than I wish you a nice weekend 🙂
  • b
    Copy code
    xml
<listview>
    <item-renderer>
        ...
    </item-renderer>
    <transformations>
        <from field="someField" to="someOtherField" type="currency" />
        <from field="someField" to="someOtherField" type="temperature" />
    </transformations>
    <data>
        ...
    </data>
</listview>
  • b
    ☝️ that would pretty neat though
  • b
    there is a new version of haxeui that im going to be releasing to haxelib soon (like tomorrow / sunday), this includes total reworks of the default and dark themes (in fact, the dark theme is now just a collection of "vars")... it would be great if anyone using haxeui could pull latest core and let me know if ive totally broken something before i release 🙂
  • b
    (component explorer has been substantially updated with more examples / variants: http://haxeui.org/explorer/)
  • b
  • i
    looks fantastic!
  • i
    except... the explorer isn't showing anything except a button called "Bob" for me

    https://plzlookat.mystupid.pictures/firefox_kRLlauN5t7.png▾

  • i
    perhaps that's all we really need to show off HaxeUI
  • b
    oh
  • b
    what browser?
  • b
    OK, should be fixed now, wasnt a haxeui issue, was an issue in the page hosting it 🙂
1...923924925...1687Latest