3 ms·
> the idea that the data representation of a UI should match the shape of the UI that's one weird assumption. I always worked with shape the data as the real w
by LoSboccacc 8y ago
> the idea that the data representation of a UI should match the shape of the UI
that's one weird assumption. I always worked with shape the data as the real world and shape the ux as the user workflows, with businness logic doing whatever transformation needed
that's the only way I see that works for long term project. if you try to semplify the real world model, you'll always come to regret it later
i.e. I'm modelling now leaflets. We're supporting many grid per spread om the datamodel, eac with their shape position and dimension, but the ux will only show one grid unless a client happens to need more than one
I guess need and solutions change dramatically between a project and a saas
- beaconstudios 8y agoyou do still need to differentiate between the data as presented to the renderer, and the data storage format. For example, you may have a hierarchical UI that wants hierarchical data, but there's no reason you can't serialize that data to a relational data store.
- LoSboccacc 8y agodepends. if you need to expose your data trough api your api will likely follow the relational model. it's then more convenient for the interpretation to happen in the presentation layer. or, splitting hair, yeah if the ui needs some hierarchy rendered out of a flat table then the javascript controller should transform it before passing to the renderer. depends where you place the cut at this point.