Representable

For example:

From @MichaelSp

classProjectincludeHyperLoop::Modelhyper_attributes:name,:a,:b,:c# or if types can't be deducedhyper_attributesname: :string,a: :integer,b: AnotherModel,c: Hash# most of time you are going to want to specify how to load, and update # typically via some APIon_createdomy.fancy.persistence.logicendon_read:fetch_the_objecton_update:do_stuffon_destroy{my.fancy.destroy.logic}end

It seems like a lot of the DSL is already working great in this gem: http://trailblazer.to/gems/representable/3.0/api.html so why make use of it under the hood then you can do this:

classProjectincludeHyperLoop::Modelproperty:nameproperty:aproperty:some_string,as: 'SomeString'property:recorded_at,type: DateTime,default: "May 12th, 2012"# and on and on...# however to make things more consistent with AR we add belongs_to, has_many, etchas_many:applications# use property definitions to define reader/writersincludeHyperLoop::Model::JSON# now you have to_json, and from_json that uses above property definitions (like Representable)on_createdomy.fancy.persitence.logicas_json# as_json will use property info to create json (like Representable)endon_readdofrom_json(my.fancy.fetch_logic)#parse and initialize properties (like Representable)endend

The only problem I see with this is that instead of "decorating" our project model we are messing with it. So how about this:

classProjectMap < HyperLoop::ModelMap# by default will deduce class name as Project (like Pundit Policies)# all the declarations go here .. instead of polluting the Project model# if no Project class is found, that's fine we will create an empty one for youend

But after writing all this, I am feeling like so what???

Can we just do this with our new "Operations"???

classProject
... whateverthislookslikeendclassLoadProject < HyperMesh::Operationparam:idallow_remote_accessdefexecute# go get your data from the API and return it probably verifying acting_user is correctendend

Here is the problem: LoadProject will want to be called from the client, but run on the server, which works fine, but we will need to make sure that we can easily marshall / unmarshall arbitrary ruby objects over the "wire". In the above case LoadProject will go get some json data from an API, then build a ruby structure, and then we need HyperMesh::Operation to re-json-ize it and send to the client, which will then rebuild it!

Need to think more on this (i.e. does Representable just run on the client) and the server operation just fetches the raw json and passes it down??

MichaelSp: I'd still prefer the first and second example. And I think it's necessary to run parts of the model logic on the server. Given a large JSON file and I only want parts of that transferred to the client, server side methods are the only way to reduce the data size. I'm not completely familiar with what operations can do, but I think using on operation for each persistence method (create, read, update, delete) is not the right way.