module Praxis

A RESTful action allows you to define the following:

Plugins may be used to extend this Config DSL.

TODO: move to Praxis proper…it’s not used here

Attributor type to define and handle the language to express filtering attributes in listings. Commonly used in a query string parameter value for listing calls.

The type allows you to restrict the allowable fields (and their types) based on an existing Mediatype. It also alows you to define exacly what fields (from that MediaType) are allowed, an what operations are supported for each of them. Includes most in/equalities and fuzzy matching options(i.e., leading/trailing ‘*` )

Example syntax: ‘status=open&time>2001-1-1&name=*Bar`

Example use and definition of the type: attribute :filters,

        Types::FilteringParams.for(MediaTypes::MyType) do
filter 'user.id', using: ['=', '!=']
filter 'name', using: ['=', '!=', '!', '!!]
filter 'children.created_at', using: ['>', '>=', '<', '<=']
filter 'display_name', using: ['=', '!='], fuzzy: true
# Or glob any single leaf attribute into one
any 'updated_at', using: ['>', '>=', '<', '<=', '=']

end

Alias it to a much shorter and sweeter name in the Types namespace.

rubocop:disable all

Alias it to a much shorter and sweeter name in the Types namespace.

Alias it to a much shorter and sweeter name in the Types namespace.

Alias it to a much shorter and sweeter name in the Types namespace.

This is an example of a handler that can load and generate www-url-encoded payloads. Note that if you use your API to pass nil values for attributes as a way to unset their values, this handler will not work (as there isn’t necessarily a defined “null” value in this encoding (although you can probably define how to encode/decode it and use it as such) Use at your own risk.

This is an example of a handler that can load and generate ‘activesupport-style’ xml payloads. Note that if you use your API to pass nil values for attributes as a way to unset their values, this handler will not work (as there isn’t necessarily a defined “null” value in this encoding (although you can probably define how to encode/decode it and use it as such) Use at your own risk

A resource creates a data store and instantiates a list of models that it wishes to load, building up the overall set of data that it will need. Once that is complete, the data set is iterated and a resultant view is generated.

stolen from Rack::Multipart::Parser

The PaginationPlugin can be configured to take advantage of adding pagination and sorting to your DB queries. When combined with the MapperPlugin, there is no extra configuration that needs to be done for the system to appropriately identify the pagination and order parameters in the API, and translate that in to the appropriate queries to fetch.

To use this plugin without the MapperPlugin (probably a rare case), one can apply the appropriate clauses onto a query, by directly calling (in the controller) the ‘craft_pagination_query` method of the domain_model associated to the controller’s mediatype. For example, here’s how you can manually use this extension in a fictitious users index action: def index

base_query = User.all # Start by not excluding any user
domain_model = self.media_type.domain_model
objs = domain_model.craft_pagination_query(base_query, pagination: _pagination)
display(objs)

end

This plugin accepts configuration about the default behavior of pagination. Any of these configs can individually be overidden when defining each Pagination/Order parameters in any of the Endpoint actions.

Example configuration for this plugin Praxis::Application.configure do |application|

application.bootloader.use Praxis::Plugins::PaginationPlugin, {
  # The maximum number of results that a paginated response will ever allow
  max_items: 500,  # Unlimited by default,
  # The default page size to use when no `items` is specified
  default_page_size: 100,
  # Disallows the use of the page type pagination mode when true (i.e., using 'page=' parameter)
  disallow_paging_by_default: true, # Default false
  # Disallows the use of the cursor type pagination mode when true (i.e., using 'by=' or 'from=' parameter)
  disallow_cursor_by_default: true, # Default false
  # The default mode params to use
  paging_default_mode: {by: :uuid}, # Default {by: :uid}
  # Weather or not to enforce that all requested sort fields are part of the media_type attributes
  # when false (not enforced) only the first field would be checked
  sorting: {
    enforce_all_fields: false       # Default true
  }
end

end

This would be applied to all controllers etc…so if one does not that It can easily add the ‘include Praxis::Extensions::Pagination` for every controller and use the class `Praxis::Types::PaginationParams.xxx yyy` stanzas to configure defaults