Servir des fichiers statiques de sous-application dans web.py

Question

J'écris une application web dans web.py (une réécriture/extension de mongs) que je veux fonctionner à la fois comme une application autonome, et comme une sous-application que les demandes peuvent être transmises à. Le problème que j'ai est que lorsqu'il est utilisé comme une sous-application, les fichiers statiques ne peuvent pas être facilement servis à partir de son propre répertoire statique. Depuis que je l'intention de distribuer ce (et non obliger les utilisateurs à combiner les fichiers dans leur répertoire de projet statique) Je veux que la structure de répertoire à:

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) 

... de sorte que tout le répertoire mongs est séparé de quelque application l'utilise.

J'ai examiné quelques possibilités pour obtenir que cela fonctionne:

• l'aide d'un gestionnaire de requêtes qui lit et envoie les fichiers du répertoire statique, comme:

  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 
  

Je ne suis pas sûr de la performance de cette solution pour les gros fichiers, et il semble que cela devrait être quelque chose que web.py peut faire par lui-même.

• Ajouter un autre répertoire statique en accédant à l'outil staticdir de cherry.py par web.py ... Je ne sais pas comment faire quelque chose comme ceci (interagir directement avec le serveur qui est en cours d'exécution sur Web.py), et je ne pense pas que cela fonctionnerait encore si je passais à un serveur Gunicorn (ou à tout serveur mais cherry.py). Fixer la façon dont web.py gère les fichiers statiques pour le rendre plus extensible ... S'il n'y a pas d'autre moyen, alors réécrire cette partie de web.py et peut-être le pousser dans le repo principal est probablement le meilleur moyen.

Alors, quelle est la meilleure façon de faire cela?

Answer 1

Dans web.py, les ressources statiques ne sont pas servies via le routeur d'application. Au lieu de cela, le serveur http vérifie l'URL de la demande avec /static. Cela signifie que si vous avez une sous-application ou non, le /static/... correspond directement au répertoire static dans l'application racine. Votre première idée de construire une classe statique fonctionnera certainement, mais vous avez raison de dire qu'il y a une implication certaine en termes de performance - bien que vous deviez l'évaluer pour savoir vraiment à quel point il est mauvais.

Une autre option, qui est pire sur le plan opérationnel, mais qui est une solution temporaire, consiste à créer un lien logiciel à partir du répertoire statique de l'application parente, dans le répertoire statique de la sous-application. à savoir

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

Ensuite, lorsque vous souhaitez accéder à un bien statique sub_app, vous frapperait une URL comme: /static/sub_app/asset. Comme cette URL commence par /static, elle sera interceptée par le serveur http et redirigée vers le répertoire static, en suivant le lien logiciel, et se résoudra en l'actif réel. En raison du répertoire sub_app, cette solution fonctionnera lors de l'exécution de la sous-application directement, ou de l'exécution de l'application parent_app. Vous devrez configurer ce lien logiciel sur tous les serveurs sur lesquels vous déployez et pour chaque environnement de développement, ce qui rend cet idéal moins qu'idéal.