2012-06-04 1 views
1

Я пишу веб-приложение в web.py (переписывание/расширение mongs), которое я хочу использовать как автономное приложение, так и в качестве суб-приложения что запросы могут быть отправлены. Проблема, с которой я столкнулась, заключается в том, что, когда она используется как вспомогательное приложение, статические файлы не могут быть легко отправлены из собственного статического каталога. Поскольку я намерен распространить это (и не требуют от пользователей, чтобы объединить файлы в статический каталог своего проекта) Я хочу, чтобы структура каталогов быть:Подавать статические файлы из суб-приложения в web.py

app_that_is_using_mongs (not mine) 
    static (which holds the app's static files - also not mine) 
    mongs (my subapp) 
     main.py (the code for mongs) 
     view (holds templates) 
     static (the static folder for mongs) 
    main.py (the code for the app that is using mongs) 

... так что весь mongs каталог отделенные от любого приложения использует его.

Я рассмотрел несколько возможностей для получения этой работы:

  • Использование обработчика запроса, который считывает и выводит файлы из статического каталога, например:

    cwd = os.path.dirname(__file__) + '/' # get current working directory 
    
    class Static: 
        def GET(self, filename): 
         """searches for and returns a requested static file or 404s out""" 
         try: 
          return open(cwd + 'static/' + filename, 'r').read() 
         except: 
          web.application.notfound(app) # file not found 
    

Я не уверен в производительности этого решения для больших файлов, и похоже, что это должно быть что-то, что может сделать web.py самостоятельно.

  • Добавление другого статического каталога путем доступа инструмент cherry.py staticdir через web.py ... Я не знаю, как сделать что-то вроде этого (взаимодействующий непосредственно с сервером, что web.py работает на), и я не думаю, что он все равно будет работать, если я перейду на сервер Gunicorn (или любой сервер, но cherry.py).

  • Устранение способа, которым web.py обрабатывает статические файлы, чтобы сделать его более расширяемым ... Если нет другого способа, переписывание этой части web.py и, возможно, ее включение в основное репо, возможно, лучший способ.

Итак, что является лучшим способом сделать это?

+0

Текущий рабочий каталог не будет путь к вашим файлам. В WSGI это может быть что угодно. – Helgi

+1

извините, это определено ранее с 'cwd = os.path.dirname (__ file__) + '/' # получить текущий рабочий каталог' (обновленный код в вопросе) – slang

+0

К сожалению, извините. Мне это удалось. Однако имя переменной является пустяком. :) – Helgi

ответ

1

В web.py статические активы не подаются через маршрутизатор приложения. Вместо этого на http-сервере есть проверка погоды, URL-адрес запроса начинается с /static. Это означает, что погода у вас есть под-приложение или нет, /static/... отображается непосредственно в каталог static в корневом приложении.

Ваша первая идея создания статического класса, безусловно, будет работать, но вы правы, что есть определенная импликация производительности - хотя вам придется сравнить ее, чтобы действительно знать, насколько это плохо.

Другим вариантом, который по функциональности хуже, но является временным решением, является создание софт-ссылки из статического каталога родительского приложения в статический каталог субприложения. т.е.

parent_app/ 
    static/ 
     sub_app/ -> parent_app/sub_app/static/sub_app 
     ... 
    sub_app/ 
     static/ 
      sub_app/ 
       ... 

Затем, когда вы хотите получить доступ к статическим актив из sub_app, вы попали URL, как: /static/sub_app/asset. Поскольку этот URL-адрес начинается с /static, он попадает на http-сервер и перенаправляется в каталог static, следуя плавной ссылке и переходит к фактическому активу. Из-за каталога sub_app это решение будет работать при запуске sub_app напрямую или при запуске parent_app. Вам нужно будет настроить эту программную ссылку на каждом сервере, на котором вы развертываете, и для каждой среды разработки, что делает это менее идеальным.

 Смежные вопросы

  • Нет связанных вопросов^_^