Skip to content
This repository has been archived by the owner on Feb 24, 2024. It is now read-only.

Handle multiple types for resources #389

Closed
stanislas-m opened this issue Apr 16, 2017 · 9 comments
Closed

Handle multiple types for resources #389

stanislas-m opened this issue Apr 16, 2017 · 9 comments
Assignees
Labels
enhancement New feature or request help wanted Feel free to contribute!
Milestone

Comments

@stanislas-m
Copy link
Member

XML, JSON... why not both? :)

This mean we should find a way to discriminate rendering. Maybe we can suffix the url (with .xml or .json), or use Content-Type HTTP header.

@stanislas-m stanislas-m added enhancement New feature or request Proposal labels Apr 16, 2017
@markbates
Copy link
Member

I like that. Maybe we could have a render.Interface function or something better named that uses the content type to render non-HTML requests appropriately like xml or JSON.

@stanislas-m stanislas-m self-assigned this Apr 29, 2017
@markbates markbates modified the milestone: 0.9.0 May 4, 2017
@stanislas-m
Copy link
Member Author

@markbates, I've pushed a new branch about this: https://github.com/gobuffalo/buffalo/tree/389-auto-resources

I think it's almost done, but I'm struggling with something:

  • On some cases, we have to add a flash message and redirect the user after the action (in the HTML case) ; but when we use JSON/XML endpoints, the result must be shown on the same page: how can we have the auto mode to make either a redirect or a rendering, according to the mime type?
    For the flash message, it can be overwritten by the user, so, maybe it's not a problem to keep it, but not using it. In a stateless condition (as an API), I don't know the behavior...
  • In HTML cases, we need to give the data to the context, to make it available in the template. That's not the case with the JSON, and we need to define a name to give to the context. From now, it has to be defined outside the auto handler, and it leads the user to duplicate the code.

What's your opinion on this?

@stanislas-m stanislas-m added the help wanted Feel free to contribute! label Jun 1, 2017
@stanislas-m
Copy link
Member Author

@markbates, I still need your input on this one. :)

@markbates markbates modified the milestones: 0.9.0, 0.9.1 Jun 19, 2017
@markbates
Copy link
Member

@stanislas-m I wonder if this should be done here https://github.com/gobuffalo/x/tree/master/responder thoughts?

@stanislas-m
Copy link
Member Author

@markbates, sure! I'll take a look on this. :)

@paganotoni paganotoni removed this from the 0.9.1 milestone Jul 10, 2017
@made2591
Copy link

Hi! This is closed, right?

@markbates
Copy link
Member

It’s actually still open. I forgot all about this idea. It’s not the same as the resource generator. The idea is that you could do something like c.Render(200, User{}) or something like that and it would render it correctly based on the content type of the request.

It’s a great idea I would love to revisit.

@made2591
Copy link

If it's ok I will have a look, maybe I can handle this ^^ I'm not a buffalo or golang expert, but it seems not so difficult to me - I will be wrong for sure. I would like to contribute. ps: I worked a lot with goa.design in the past, maybe could be useful to someone else for something else...

@markbates
Copy link
Member

Please! I’d love to see someone take the reigns.

@markbates markbates assigned markbates and unassigned stanislas-m Feb 14, 2018
@markbates markbates added this to the 0.11.0 milestone Feb 14, 2018
markbates added a commit that referenced this issue Feb 14, 2018
* wip r.Interface

* renamed render.Interface to render.Auto

* cleaned up tests for auto

* Handle multiple types for resources fixes #389

* removed a few unneeded lines in the generated resource code

* fixed broken test
Shivakishore14 added a commit to Shivakishore14/buffalo that referenced this issue Feb 23, 2018
added support for RSA, ECDSA, RSAPSS

Handle multiple types for resources fixes gobuffalo#389 (gobuffalo#919)

* wip r.Interface

* renamed render.Interface to render.Auto

* cleaned up tests for auto

* Handle multiple types for resources fixes gobuffalo#389

* removed a few unneeded lines in the generated resource code

* fixed broken test

Fix Bazaar VCS behavior (gobuffalo#923)

* Normalized keep files like in Rails (empty .gitignore => .keep)
* Moved VCS as a meta app info.
* Ensure Git & Bazaar are quiet on app creation.
* Ensure .gitignore files are properly named for Bazaar (.bzrignore, see gobuffalo#901).

Fixing the godoc for mount

Code in go doc comments has to be indented for it to show up
pre-formatted on godoc.org

removed the unneeded willie dep that was causing travis to break

Set default sign method to HMAC and added some docs

Add Buffalo logo to the README (gobuffalo#926)

this makes r.Auto work with paths such as /admin/users not just /users

added GetKey func to Options for enabling user to extend their own implementation of getting key, moved test certs from data/ to test_certs/

added jwt.SigningMehod parameter in GetKey in Options struct

reduces inlined css used in the error page

show the headers on the error page

webpack/style_regex: change regex to catch both .sass and .scss file extensions

webpack/style_regex: Apply change to asset glob pattern
markbates added a commit that referenced this issue Feb 26, 2018
* wip r.Interface

* renamed render.Interface to render.Auto

* cleaned up tests for auto

* Handle multiple types for resources fixes #389

* removed a few unneeded lines in the generated resource code

* fixed broken test

* wip moving to gobuffalo/pop

* updated a dep

* wip r.Interface

* renamed render.Interface to render.Auto

* cleaned up tests for auto

* wip moving to gobuffalo/pop

* Handle multiple types for resources fixes #389

* updated a dep

* remove the unneeded go get willie call

* Added a command to upgrade v0.10.3 to v0.11.0

* added updating of buffalo project dependencies

* improved the updater to work a bit better
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request help wanted Feel free to contribute!
Projects
None yet
Development

No branches or pull requests

4 participants