I'd like to append a serialization of the current scope with my json response. While the current scope is available to the ActiveModel:: Serializer, it's not necessarily associated with the model being serialized; so I'm unsure how to include it.
My first instinct is to just create a wrapper which merges the model serialization and scope serialization. I think this wrapper would break some conventions though.
Is there a pattern for side-loading this context?
Related
Just learning about serializers and was wondering what's going on under the hood. Does it actually change your db query or do serializers just wrap around your model and then format the data nicely before passing it to your controller?
Normally, no change is made to any db query. Instead, the model handles querying the db for data and instantiating an object, then the serializer uses that instance and your serialization logic to format a response that the controller renders. Note that you can also serialize POROs.
I'm just getting into knockoutjs and have what is probably a pretty fundamental question.
Is it "best practice" to have a javascript version of my model on the client side to mirrow my server side.
So when I receive say an order object which will have a person object, item object and some properties such as price and so on, is it the norm to then have an order model coded on the client side that I then map my json to?
The ebenfits of that would be intellisense etc but obviously there is also then code duplication.
What is the industry standard for handling this?
There is no industry standard.
I prefer to serialize my object into json and use knockout.mapping for making observable with them
http://knockoutjs.com/documentation/plugins-mapping.html
You don't have intellisense but in the other hand you don't have code duplication
Key feature of knockout is bindings, for bidirectional binding (update UI after model changed) you should use observable properties. It isn't critical are observable properties part of model or viewmodel or anything else. Also you can use mapping plugin for direct generation viewmodel from JSON. This plugin make all properties observable. But this is not useful for models with methods and inner properties.
While reading the Tire doc, I was under the impression that you should use either mapping or to_indexed_json methods, since (my understanding was..) the mapping is used to feed the to_indexed_json.
The problem is, that I found some tutorials where both are used. WHY?
Basically, my app works right now with the to_indexed_json but I can't figure out how to set the boost value of some of the attributes (hence the reason I started looking at mapping) and I was wondering if using both would create some conflicts.
While the mapping and to_indexed_json methods are related, they serve two different purposes, in fact.
The purpose of the mapping method is to define mapping for the document properties within an index. You may want to define certain property as "not_analyzed", so it is not broken into tokens, or set a specific analyzer for the property, or (as you mention) indexing time boost factor. You may also define multifield property, custom formats for date types, etc.
This mapping is then used eg. when Tire automatically creates an index for your model.
The purpose of the to_indexed_json method is to define a JSON serialization for your documents/models.
The default to_indexed_json method does use your mapping definition, to use only properties defined in the mapping — on a basis that if you care enough to define the mapping, by default Tire indexes only properties with defined mapping.
Now, when you want a tight grip on how your model is in fact serialized into JSON for elasticsearch, you just define your own to_indexed_json methods (as the README instructs).
This custom MyModel#to_indexed_method usually does not care about mapping definition, and builds the JSON serialization from scratch (by leveraging ActiveRecord's to_json, using a JSON builder such as jbuilder, or just building a plain old Hash and calling Hash#to_json).
So, to answer the last part of your question, using both mapping and to_indexed_json will absolutely not create any conflicts, and is in fact required to use advanced features in elasticsearch.
To sum up:
You use the mapping method to define the mapping for your models for the search engine
You use a custom to_indexed_json method to define how the search engine sees your documents/models.
I am working on a project that will take custom validations on models and translate them into javascript to be run on the client side. We are currently passing in the model, and the validation method (as an UnboundMethod ).
JStranslator(model, Validator.instance_method(:validate))
What I want is to get all the UnboundMethods that get used for validating the model because our translator leverages the AST representation of the methods (using 'live-ast'), therefore the model_name.validators will not work (it returns an array I think). I need to get all custom defined validation methods that are defined inside the model itself as well as all validators the model uses.
Validations are stored as callbacks, so you may want to play around with those:
Model._validate_callbacks # do something
Resources:
https://github.com/rails/rails/blob/master/activemodel/lib/active_model/validations.rb
https://github.com/rails/rails/blob/master/activemodel/lib/active_model/callbacks.rb
http://api.rubyonrails.org/classes/ActiveRecord/Callbacks.html
Happy to help more if you get stuck.
I'm pulling records off from a message queue in JSON format and want to use ActiveRecord's .build method if I can to simply pass in the record and build the object.
How do I do this? Are there any downsides to this approach?
In principle you can use YourModel.new.from_json(json_string) but how that behaves depends on the boolean ActiveModel::Base.include_root_in_json. Set that to false first if your json is a straightforward hash/object or leave it as true (the default) if your json is the kind of nested hash produced by to_json (again, by default).
All that method does is decode the json to a hash and calls self.attributes = hash, so you could just as easily do that yourself.
With respect to downsides, there really aren't any specific to this process. You're essentially doing the same thing you'd do in a standard create controller method, replete with validations, attr_accessible restrictions and so on.