Wanted to offer a point of view on " 3. Keeping the views up-to-date. " I do not have any empirical results to suggest it a viable alternative, but still..
I think the problem is so difficult due to the cardinality of the set of possible relations/dependencies that the views can represent. So an approach would be to a) separate out the type object relations a given view can support. b) provide explicit wiring through out the stack, for the most 'frequently' used relations c) allow to to attach 'custom abbreviation' objects for each node in the explicit relation and onto the relation itself. And allow application developer to write a bespoke 'interpret' of those custom abbreviations. In more practical terms this would translate into a) Example of 'frequently used relation': Master-Detail Object hierarchy with a primary key on master an a foreign key into 'detail'. b) The above would require a pre-build Om transactional closure on interactive events (eg Om can capture and 'bundle up' updates from the user interaction into uniform 'buckets') And then a client-to-backend communication to a server that can 'continue' the update onto the data store. c) the server back-end allows an application developer (outside of this pre-wired) framework to attach 'abbreviations' to the primary, foreign keys and the pk-fk relation themselves. and return back to the client. Client can then define using om-sync again a mechanism to decide how to interpret those abbreviations. Put it other way, there is a benefit to manage state of a particular user agent (browser) in one place. Having to manage on the back-end is probably not the right thing (again, subjective). Om provides a transaction state management semantic on the browser side. The above attempts to simplify the type of 'views' (relations) to be supported. Then pass on 'the state closure' to the server side, apply it, and then send back the state updates using the 'abbreviation objects' on a particular pre-wired 'relation type' (view) . Vladislav -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
