EDIT: I am going to break this into two more specific questions.
I am trying to understand best开发者_如何学JAVA practices and patterns for client side JavaScript development. In particular, what do you do to manage more complex data models on the client?
As an example, say you where managing some sort of store catalog online, and had a Product, with it’s pretty typical properties: { id, description, price, etc… }. But the product also has a set of categories that it could be associated with, and therefore two more lists needed to be fetched: AvailableCategories and AssociatedCategories. Of course, to make matters more complex, your association of categories to tables is not a simple join, but has meta-data like a scalar number from 1-10 that describes how strongly associated the product is to the category. And then say there are four or five other associations, of which one has an “Available” table that might require paging (for instance, maybe you associate the product with something that has a million items in the table, and you want to pull down only 100 of them at a time, searchable and sortable, of course).
My point is, there are lots of models, along with join associations with meta information, some data can be pre-fetched or statically downloaded on the page load, while some has to be dynamically fetched. And of course, you don’t just want the base models, but “observables” as well, so that if someone chooses a color to associate with your product, you would be notified (for free) someplace else on the page of the changes.
I am thinking of moving to a client side MVC framework, like SproutCore, but would like to see some lighter weight options and patterns. I would appreciate hearing what you use, why you use it, and any other thoughts on this problem space.
Thanks.
When I build javascript apps, I don't start by looking at the data model, but rather the user interactions that the app will support. Then I design those interactions by making very specific ajax RPC calls that only populate exactly the view I'm looking at. Same with the operations in that view, I have very specific ajax RPC calls that does exactly what that view requires.
In some cases I do end up with more generic RPC calls, where more views can share similar data, but I refactor that when I reach it, I don't start modelling like that.
So far I typically, as you say, have some static categories etc to read up at start of the application, but I've managed to avoid having huge complicated cached data models in javascript memory that needs syncing with the backend.
In this I've found the MVP pattern to be a much better choice than MVC - driving all my application code with events.
Not sure I understand your question, but I think I'm in a similar case:
I have a quite complex model, and have to maintain a client side version of it. Calls to the model are made asynchronously, and model manage caching and pre-fetching. When an update is made on a model, it fires an event so UI components are notified.
I'm not using any framework to implement the data models. (But i use YUI for ajax communications and UI widgets)
I'm not sure I understand. Are you finding it difficult to work with JSON objects due to the complexity of their corresponding server side objects?
Ruby on Rails offers the best of both worlds: the js.erb template. Have your AJAX request accept js and create a js.erb template that can reference your Rails object directly, including all associations, etc. This template will use javascript code that can access values from your Rails object using the erb notation:
<%= @object.attribute %>
I am thinking of moving to a client side MVC framework, like SproutCore, but would like to see some lighter weight options and patterns.
Sammy.js is fantastic if you want something lightweight. I'm in the middle of writing a single-page web application (80% done). It's getting/setting all its data from a RESTful web service based on ~30 tables and a bunch of "views". I'm stunned by how easy it has been so far and Sammy surely helps a lot.
精彩评论