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

Add Resource.Content #4622

Closed
bep opened this Issue Apr 15, 2018 · 9 comments

Comments

Projects
None yet
3 participants
@bep
Member

bep commented Apr 15, 2018

Which in most cases (JSON etc.) will be a String. Page already has this, and it is of type template.HTML.

The current workaround for this is, for the non-page resources, I suppose, doing Readfile, which does not look too pretty, and it may be hard to get the paths correct.

One question: Anyone know about a current use case for doing $image.Content?

/cc @kaushalmodi @moorereason @regisphilibert and gang

@bep bep added the Enhancement label Apr 15, 2018

@bep bep added this to the v0.39 milestone Apr 15, 2018

@bep bep self-assigned this Apr 15, 2018

@regisphilibert

This comment has been minimized.

regisphilibert commented Apr 15, 2018

Just making sure I understand this feature.

It is the addition of a .Content property on the resource object which evaluates its content no matter its type.

(So we don’t have to identify its type in order to know which property to call to output its content)

@regisphilibert

This comment has been minimized.

regisphilibert commented Apr 15, 2018

One question: Anyone know about a current use case for doing $image.Content?

For svg yes. An easy way to include it inline.

@bep

This comment has been minimized.

Member

bep commented Apr 15, 2018

It is the addition of a Content property on the resource object which evaluates its content no matter its type.

Yes. So, for Page it would be what you know as .Content (where we also have RawContent). It think .Content as in "what we publish" would be semantically correct for all types of resources. For a JSON file we just copy it to public, so Content would just be the string content etc.

@RealOrangeOne

This comment has been minimized.

Contributor

RealOrangeOne commented Apr 15, 2018

One question: Anyone know about a current use case for doing $image.Content?

A potential use for this is to base64 encode it for the src attribute. As https://en.wikipedia.org/wiki/Data_URI_scheme describes. However perhaps this is out of scope for this feature?

@regisphilibert

This comment has been minimized.

regisphilibert commented Apr 15, 2018

Does this mean you would have to pick a scenario for any file main type or sub type ?

Because JSON and PDF for example could not really behave the same and yet they share the same main type ?

I wonder what kind of fallback could be used as .Content for files which clearly could not present any. nil ?

@bep

This comment has been minimized.

Member

bep commented Apr 15, 2018

Because JSON and PDF for example could not really behave the same and yet they share the same main type ?

I suspect that you complicate this more than needed.

Both JSON and PDF can be represented as a set of bytes. No problem there. You will have to use this as you see fit, this is not a "content viewer"; that is what the browser and RelPermalink is for.

This is for some rare use cases where you want to display content inline. Code examples from files and similar.

@bep

This comment has been minimized.

Member

bep commented Apr 15, 2018

That said, we could probably add the full media type to Resource as well, but you should create a separate issue for that and provide a use case.

@regisphilibert

This comment has been minimized.

regisphilibert commented Apr 15, 2018

I suspect that you complicate this more than needed.

I often do.

Both JSON and PDF can be represented as a set of bytes.

But their .Content output will still be different. I'm just trying to understand what will happen if I call .Content on an application file other than JSON.

  • (application/json Resource).Content => outputs a json string
  • (application/pdf Resource).Content => outputs a set of bytes ?
@bep

This comment has been minimized.

Member

bep commented Apr 15, 2018

But their .Content output will still be different.

I would say that there should be no surprises.

How I currently see it it is:

  • Page => template.HTML
  • All (current) others are String

So, template.HTML is just a special Go string marker type that tells the template parser not to do magical escaping (is what safeHTML func does to strings).

So, getting JSON and all the images as a string is what you do today when you do readFile and is also what base64 and other relevant funcs expects (note that all of them also handles template.HTML as a string, so this should really just work) .

So the use case of @RealOrangeOne would just work, I think:

src="{{ (.Resources.GetMatch "mylogo.png").Content | base64Encode }}

I cannot think of any example where a []byte slice would be useful, and if so, we should add a bytes template func to do the conversion.

bep added a commit to bep/hugo that referenced this issue Apr 15, 2018

Make Page.Content a method that returns interface{}
To prepare for a `Resource.Content` method.

See gohugoio#4622

bep added a commit to bep/hugo that referenced this issue Apr 15, 2018

bep added a commit that referenced this issue Apr 15, 2018

Make Page.Content a method that returns interface{}
To prepare for a `Resource.Content` method.

See #4622

@bep bep closed this in 0e7716a Apr 15, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment