How to de-serialize model attributes manually about epf HOT 6 CLOSED

Thanks for the kind words. I think what you want here is session.remoteCall. This gives you sugar around custom endpoints.

from epf.

Thanks for the quick reply!

It wasn't clear from my question but the use case I had in mind was returning a package of data, like an initial login packet containing a user, an account model and some other stuff.
I saw session.remoteCall but I think that seems to be related to calling custom endpoints that specifically relate to a single model.

I could make a virtual model that embeds the user and so-on and load the models that way, and maybe that is the correct answer here, but I just thought it was neat that EPF is close to allowing a more ad-hoc approach to loading models from an irregular json packet.

So you know it would be convenient (and quite new user friendly too I think), to be able to do something like this in the route or controller without having to go and create a virtual model to represent that packet just for the sake of the framework rigidity.

$.get("some/custom/endpoint", function(data){
    user = App.User.create(data.user);
    session.merge(user);
    user = App.Account.create(data.account);
    session.merge(account); 
});

Well you can do it of course, except for the auto attribute mapping?

Cheers!

from epf.

If it is an irregular packet then the serializer will be hard to use anyways. Epf is really good at side-loading models as well as handling embedded models. In our app we send down the current user with a bunch of side-loaded models (which sounds similar to what you are describing). I think this combination should work well with session.remoteCall. At some level you can think of remoteCall as just combining a custom endpoint with the serializer.

from epf.

Hi Gordon,

I played around with remoteCall but couldn't see how to make it work in this case.

I found another ticket where you were discussing how to load static data during initialize, and that is more like what I wanted to do here, except the initial data comes from the server.

So this works exactly like I need it to:

$.get "/api/loginPackage", (data) =>
  user = @adapter.didReceiveDataForFind({user: data.user}, App.User).content[0]
  @session.merge(user)
  account = @adapter.didReceiveDataForFind({account: data.account}, App.Account).content[0]
  @session.merge(account)

But it seems like it is peeking under the hood more than we would like.

If Model.create could hook into the adapter/serializer like that under the hood then that would be a nice API I think:

$.get "/api/loginPackage", (data) =>
  user = App.User.create(data.user)
  @session.merge(user)
  account = App.Account.create(data.account)
  @session.merge(account)

Any reason that's a bad idea? I'm happy to have a go at it if not.

Cheers.

from epf.

Ideally I would like to keep the models agnostic of the adapter/serializer layer. I think the way to do this might be to actually clean up the adapter layer to make doing things like this more conventional.

from epf.

OK fair enough.

Yes if the adapter presented more of a public facing API to allow ad-hoc cleansing and manipulation of server data that would be good to.
I'm just happy that I can actually do this now, with ED I had 4 separate load calls because I couldn't work out how to make it process a one-off packet like this.

I would say that while separation of model/adapter concerns makes sense architecturally, I think it also pays for a framework to be pragmatic at times. The Model.create case is a good example of where rails would probably make life easy for the (casual) user and automatically give the current adapter (if present) a chance to cleanse the input data before applying it to the model.
Of course it's easy for the user to orchestrate the pieces manually once they have an understanding of the architecture, but its things like that which make Ember a bit frustrating to get started with and IMHO it suffers a bit from being too idealistic at the expense of pragmatism.

Anyway thanks again for the really quick feedback and for EPF.

from epf.