portal.imageDataUri() or rather portal.imageStream()

[ComLock]

In order to render images server-side I would like a portal.imageDataUri function similar to portal.imageUrl.

Ref: http://repo.enonic.com/public/com/enonic/xp/docs/6.12.2/docs-6.12.2-libdoc.zip!/module-portal.html#.imageUrl

The type and params arguments are probably not needed.

Instead you might want encoding with base64 as the default.

Usecases:

• Building GraphQL backends so a single request gives you all you need.
• Building other services that delivers everything in a single request.
• Building services which works without login.

[ComLock]

The current workaround is using http-client on an imageUrl, but that requires auth by username and password. Since you cannot get the password of the currently logged in user, that's a problem.

lib-context.run doesn't help with http-client requests

[sigdestad]

Can you please provide a use case?

[ComLock]

I think we can go lower: portal.imageStream({scale:, ...}) (should handle context) Then it's easy for me to code the dataUri encoding or whatever on top of it.

In terms of use cases I listed 3 in the initial report. Basically whenever you want to make some backend that gives you all you need in a single request.

Typically this is good for single page applications, for instance built in angular or react. I don't know enough about PWA to know whether it might be useful there.

[ComLock]

@GlennRicaud One could also use the portal.imageStream in guilotine, so the GraphQL backend can serve images directly.

[sigdestad]

GraphQL does not support binary data

[sigdestad]

HTTP2 solves your multi-request problem, so the server can actually push resources back to the client even before it asks for them. Why do you want to serve images that are protected to a non-protected interface?

[ComLock]

base64 encoded datauri is not binary

[GlennRicaud]

All of this is a bit too specific and workaround/hacky. As discussed: What you would like to have is more an image library that returns the image scaled/compressed/... Then you can do whatever you want and transform it to base64.

But again as Thomas said. If you need to serve forbidden contents to unauthenticated users, there is something wrong

[ComLock]

The interface can be protected. That will not help as http client on imageUrl requires password.

I guess what you are saying is expose the images so imageUrl works from the browser, and let Enonic and the browser cache the scaled image.

When you have a server-side rendered webpage, you can preload images.

When you have a dynamic client-side rendered page you cannot preload the images. So after you fetch the html to display, then the browser will start fetching the images. In other words there is a delay. I you get all you need in a single request, then the images are ready to render as they are part of the html. No delay.

[ComLock]

The client side user is logged in via SSO and is authenticated. So stop thinking about someone accessing something they don't have access too. That was a poorely stated argument from me. That is not the issue.

[ComLock]

If I had an image library I could use getContent and getAttachment on the image to get the binary stream and feed that to the image library scaler. Hopefully the image library scaler would do server side caching like enonic does for imageUrl.

[ComLock]

There are benfits to inlining. That's what many of the big companies do. Typically SVGs though.

[GlennRicaud]

SVG are a bit different, but okay I got the idea now.

[sigdestad]

We had a discussion on phone. Ideal solution would be actually be a more open Guillotine app, but we should also expose image service API internally in XP too! Christian will create feature requests

[sigdestad]

We agree that the imageService should be available for back-end purposes, but this is not a prioritized task at the moment. Hardcore developers can look at the java level how things are done and access this. Closing the issue.