You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fragments are designed to be reusable and flexible, but that comes at the cost of a verbose API. For the simplest use cases, it should not be necessary to declare a new DS.ModelFragment class. This could be possible by introducing some sugar on top of the current API, which would allow for reuse/flexibility when needed.
App.Customer=DS.Model.extend({// Shorthand for `DS.hasOneFragment`name: DS.obj({first: DS.attr("string"),last: DS.attr("string")}),// Shorthand for `DS.hasManyFragments`invoices: DS.arr({sum: DS.attr("number"),items: DS.hasMany("items")}),// Shorthand for `DS.hasManyFragments` that accepts 'primitive' typeloginDates: DS.arr("date")});
It should be trivial to auto-generate anonymous DS.ModelFragment sub classes in the DS.obj and DS.arr property helpers, however this syntax raises a few issues:
What serializers do anonymous fragments use? I doubt it is acceptable to be locked into using DS.JSONSerializer. Perhaps a default fragment serializer can be introduced that can be overridden in the container? Naming the generated fragment using a combination of the model type and attribute name seems wrong.
DS.arr and DS.hasManyFragments cannot be used interchangeably since passing a string to DS.arr would introduce ambiguity, e.g. is the string an attribute type or a fragment type? This may be a good thing.
The idea of anonymous model classes is a dubious one, however I cannot readily point to why. Another downside to this syntax is that it's not immediately obvious from the naming what the expanded form is, e.g. obj doesn't have readily apparent connection to hasOneFragment.
The text was updated successfully, but these errors were encountered:
Fragments are designed to be reusable and flexible, but that comes at the cost of a verbose API. For the simplest use cases, it should not be necessary to declare a new
DS.ModelFragment
class. This could be possible by introducing some sugar on top of the current API, which would allow for reuse/flexibility when needed.@silvinci's proposed a concise shorthand syntax in his comment on the epic thread that started this all:
It should be trivial to auto-generate anonymous
DS.ModelFragment
sub classes in theDS.obj
andDS.arr
property helpers, however this syntax raises a few issues:DS.Store#createFragment
, which means they would need to be created via literals proposed in Allow fragment attribute setters to accept object/array literals #10 (orDS.FragmentArray#createFragment
).DS.JSONSerializer
. Perhaps a default fragment serializer can be introduced that can be overridden in the container? Naming the generated fragment using a combination of the model type and attribute name seems wrong.DS.arr
andDS.hasManyFragments
cannot be used interchangeably since passing a string toDS.arr
would introduce ambiguity, e.g. is the string an attribute type or a fragment type? This may be a good thing.The idea of anonymous model classes is a dubious one, however I cannot readily point to why. Another downside to this syntax is that it's not immediately obvious from the naming what the expanded form is, e.g.
obj
doesn't have readily apparent connection tohasOneFragment
.The text was updated successfully, but these errors were encountered: