【问题标题】:active storage / clean files url活动存储/清理文件 url
【发布时间】:2018-09-20 21:57:22
【问题描述】:

关于同一个问题的多个问题,主动存储返回文件url的方式

现在使用默认设置,以下(云或本地)以某种方式返回以下内容:

_domain/_path/_superlong_hash/_original_filename._ext

鉴于回形针或许多其他现有的 gem,_path/_superlong_hash/_original_filename._ext 部分可以自定义,最终可能会在任何文件的干净 url 中结束

意思是:

  • 有没有办法用更自定义的东西“代理”_path
  • 有没有办法避免_superlong_hash
  • 有没有办法即时(或上传)自定义文件名?

要使其成为单行,如何自定义文件网址?

我在这里和那里看到人们最终创建自定义控制器来提供具有体面 url 的文件,但让我们承认这是不行的(恕我直言)

【问题讨论】:

    标签: ruby-on-rails upload cloud rails-activestorage


    【解决方案1】:

    我希望 ActiveStorage 很快证明我错了,但在编写 Rails 5.2 时,直接的答案似乎是你必须选择“不通过”选项,将你自己的控制器组合在一起并大量修补 ActiveStorage 以暴露文件。

    有关代理,请参阅:

    https://github.com/rails/rails/issues/31419

    https://github.com/rails/rails/pull/30465

    • 尤其是 georgeclaghorn 的反应很有趣

    重命名文件:

    @user.avatar.blob.update(filename: 'NewFilename.jpg')
    

    操纵 _superlong_hash / url

    我没有很好的答案。尽管 ActiveStorage 使上传文件变得非常容易(并且在某种程度上易于操作),但它却将 Rails 固执己见的软件哲学推向了边缘,使得通过抽象方法生成 url 来绕过它的晦涩难懂。 ActiveStorage 不提供内置方法来执行基本操作,例如生成后的文件和变体的永久或直接链接。因此,文件/图像缓存和漂亮的 url 目前似乎无法通过 ActiveStorage 实现开箱即用。

    【讨论】:

    • 恕我直言,我想补充一点,我认为 ActiveStorage 目前不推荐给任何人,但开发人员的应用程序与 Basecamp 的行为非常精确匹配。此外,ActiveStorage 的路由劫持是一个主要问题/错误github.com/rails/rails/issues/31228 对于其他所有人来说,CarrierWave 是一个更明智和可配置的选项。
    • 持有相同观点,但基于越来越多的人将使用代理服务(cloudinary、imgix 等...或任何其他等效服务)这一事实,事情可能会开始ONLY 对上传部分有意义。这并不能使它成为一个完美的解决方案,我们都可以同意,如果必须满足所有要求,主动存储会以某种方式丢失一些东西
    猜你喜欢
    • 1970-01-01
    • 2021-12-19
    • 2019-03-21
    • 2018-03-06
    • 2019-05-21
    • 1970-01-01
    • 1970-01-01
    • 2020-11-04
    • 2023-04-06
    相关资源
    最近更新 更多