Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any easier way for rendering custom properties #155

Open
PikachuEXE opened this issue Sep 14, 2015 · 2 comments
Open

Any easier way for rendering custom properties #155

PikachuEXE opened this issue Sep 14, 2015 · 2 comments

Comments

@PikachuEXE
Copy link

I am using cells (concept cells)
So I kind of expect support for similar syntax in representable
But this is what I need for rendering a controller loaded neighbourhoods (with a city):

class MyRepresenter < Roar::Decorator
          include Roar::JSON

          self.representation_wrap = :city

          collection :neighbourhoods, getter: -> (args) {
            args[:neighbourhoods]
          } do
            property :name
          end
end

MyRepresenter.new(city).to_json(neighbourhoods: my_custom_neighbourhoods)

I kind of expect

class MyRepresenter < Roar::Decorator
          include Roar::JSON
          include Roar::SomeMagicModule # :P

          self.representation_wrap = :city

          collection :neighbourhoods do
            property :name
          end

          private

          def neighbourhoods
             args[:neighbourhoods] # Still not the best form but still better than setting a lambda in option
          end
end

MyRepresenter.new(city, neighbourhoods: my_custom_neighbourhoods)

I understand the class might also used for parsing input
But is there anyway to NOT use option to get custom input?
Or I should use a custom class (e.g. Struct) for carrying the data into the representer?

@apotonick
Copy link
Member

I recommend using a domain object (e.g. OpenStruct) that reflects your concern and pass that into the representer.

I keep repeating myself, but forms, cells, and representers are no data-mappers, they use data objects to (re-)present them, and even though they provide some tools for mapping this should happen on the outside.

In the coming months I will push the idea of twins and ROM since domain/data modelling must be a first-class citizen of software engineering.

@apotonick
Copy link
Member

BTW, if you want neighbourhoods to be called on the decorator, you can do

collection :neighbourhoods, exec_context: :decorator, ..

But this still won't give you access to the args.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants