Fair enough. Probably why Ember Data isn’t ready for primetime yet. Should probably mention this in the Ember Data project. It’s a use case that we see often.
That’s an interesting use case, though. I’ve got a similar one in my app, too. I have some fairly complicated rendering logic duplicated between my backend and my front end. They’re in different languages. The front end has to do live rendering of it, and the back has to do the final rendering.
It very much feels like it’s violating DRY, except that I’d have to build some form of advanced language-agnostic meta-pattern or language to place that logic in only one place. Wasn’t really sure how to tackle that. Also, the front side and back side logic is subtlely different because of different language features and the fact that one of them is built in an Async front side, whereas the other is built in a more Sync language.
What would probably be really cool is if we had some form of validation API we could communicate against in Ember-Data… something like the Active Record pattern by Martin Fowler… whereby there are two APIs - one for the schema, and one for the data. That schema could also specify validation information which could inform ember of how to validate on various data.
Going on from there, it’d be quite cool if we had our server partially building out the JS that makes up the Ember application to provide common algorithms across server and client in only one place… using some kind of meta-language.
But I digress, and this is sounding like “Intentional Programming” now…