search

ftlabs / fruitmachine

View rendering engine
MIT License
247 stars 18 forks source link

Proposed changes to the ways models work #6

Closed wilsonpage closed 11 years ago

wilsonpage commented 11 years ago

After speaking with Jamie (@orangemug), he raised concerns about how users were encouraged to couple models into their Views via the View#data API.

Suggested changes:
  1. Models should always be passed into Views explicitly with the key model.
  2. If a plain JS object is passed instead of a Model instance, FruitMachine will upgrade it to a model internally (bad, but required to fulfil the bad way we manage data in the web app).
  3. If third party models are to be used, they must conform to a basic API (.get(), set(), toJSON()) or define an 'adaptor' to translate the FruitMachine.Model API onto the foreign API.
  4. When we are interpreting server generated view JSON on the client on initial (server rendered) page load. FruitMachine could emit a 'modelfound' event passing the model and the associated view to a callback. This is the developer's opportunity to swap out this 'detached' temporary model with a reference to a 'live' model if they wish. This means that if the application wishes to make changes to the 'live' model, the server rendered view will hear them and be able to update.
wilsonpage commented 11 years ago

New model changes: 41980531bf453d921b3aee1d7bc2662990064772

wilsonpage commented 11 years ago

Currently models must have a .toJSON() method on them to work with FruitMachine. If anyone can think of a clever, clean way of supporting models that don't have this method, please say so.