在Play 2.x中提供动态内容 [英] Serving dynamic content in Play 2.x

查看:60
本文介绍了在Play 2.x中提供动态内容的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在某种程度上,我正在做与这篇文章非常相似的事情:解决方案

不管这是否是个好主意,Play都没有真正的问题!在public/文件夹中提供资产.

可能导致它似乎无法正常工作的唯一原因是,在编译应用程序时,public/文件夹中已经存在的任何资产都将被编译为.jar文件.如果您编写的新文件的名称/路径与已编译到该.jar文件中的文件/名称/路径相匹配,则只需将已编译的文件送回,而不是新文件.如果.jar文件中不存在该文件,则可以将其放回原处.

这可能不是一个好主意,但是我认为这对于我们正在尝试的工作是可以接受的解决方案.

On some level, I'm doing something very similar to this post: how to serve dynamic content in playframework 2

Which is that I have a web app where clients can specify various parameters and we have the Play! server initiate a process that generates a custom image file...which then needs to be served back to that client, preferably by Play!

Anticipated image life expectancy could be anywhere from several seconds to several minutes (maybe even hours). From that angle, we have reasons to believe that attempting to send back the image data directly with the response is not a viable approach...and instead are going to send back a URL to that dynamic image.

I would also very strongly prefer to NOT rely on a separate HTTP server being set up to serve up these dynamic images for a variety of reasons. I believe the reasons are many, including but not limited to... maintaining a simpler architecture for both the developer work environments as well as the production servers. We have a very small/restricted user base with very few concurrent users (I don't believe serving up these images needs to be terribly high performance anyway - assuming Play! can serve up these dynamic images, I find it hard to imagine that the performance wouldn't be perfectly acceptable considering the simplicity tradeoff).

I've read that Play! assets in the public/ folder are compiled into an .jar file build/compile time which seems to explain why my tests of dynamic image generation and serving back don't work as expected - the results served back are always from the previous build.

Can anyone suggest a way of serving dynamic assets back without relying on another server?

解决方案

Regardless of whether this is even a good idea, there is no real problem with Play! serving up assets in the public/ folder.

The only thing that can cause it to appear to not work is that any assets already existing in the public/ folder when the app gets compiled will get compiled into a .jar file. If you write a new file with a name/path that matches one that was compiled into that .jar file, you simply get the compiled file served back, not the new file. If the file does not exist in the .jar, it is served back just fine.

This may not be a terribly good idea but I think this is an acceptable solution for what we are attempting to do.

这篇关于在Play 2.x中提供动态内容的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆