Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Secondary assets should use a path type of parameter #110

Open
PonteIneptique opened this issue Jan 10, 2018 · 4 comments
Open

Secondary assets should use a path type of parameter #110

PonteIneptique opened this issue Jan 10, 2018 · 4 comments

Comments

@PonteIneptique
Copy link
Member

Currently, when setting up the following

nemo = Nemo(
    name="InstanceNemo",
    app=flask_app,
    resolver=resolver,
    base_url="",
    css=["assets/css/theme.css"],
    js=["assets/js/empty.js"],
    statics=["assets/images/logo.jpeg"]
)

assets are responding to URIs /assets/nemo.secondary/css/theme.css, /assets/nemo.secondary/js/empty.js and /assets/nemo.secondary/static/logo.jpg when creating their URIs using url_for(".secondary_assets", filetype="js", "logo.jpeg")

This is really bad design. It should be possible to do /assets/secondary/assets/images/logo.jpg and avoid name collision...

@aurelberra
Copy link

I can confirm that the current scheme is confusing…

@PonteIneptique
Copy link
Member Author

There is some kind of issue with that though... Technically, the file can be anywhere, which means computing the pass (here /assets/images/logo.jpg) is easy but in a case where the user would use /home/username/asset/logo.png it's not as clear.

Maybe the solution is to move to a directory serving system instead of a file one.

@PonteIneptique
Copy link
Member Author

PonteIneptique commented May 21, 2018

I actually thought the code could be a quick fix I'd do this morning but the connection of this code and how to deal with it needs more time than I can give it, I'll look forward @MrGecko or @sonofmun or @balmas taking care of it.

My first idea was to switch js, css and statics to directories such as :

"""
    :param css: A directory containing CSS files that needs to be loaded on every page
    :type css: str
    :param js: A directory containing Javascript files that needs to be loaded on every page
    :type js: str
    [...]
    :param statics: A directory of files that will be served as a second directory
    :type statics: str
"""

(Note that I would probably rename the internal value self.__assets__["static"] to self.__assets__["statics"] to be the same as the init parameter. Would make sense.)

Such a change would remove the ability to link css and js from the web (which is currently possible). I believe it would be okay but I cannot make this choice alone. In the spirit of simplifying this function, I think it's better to force people to put their JS in local.

I believe to give a little more freedom on this, if we were to remove the ability to link external URI scripts and CSS, I would add empty templates for css and javascript that could easily put back this function.

The issue that will arise is the existence of plug-ins : additional CSS, JS and Statics of plug-ins are working the same as Nemo and we need to take that into account to have something "stable". This actually questions the necessity of plug-ins as they are currently built, but that's for another issue (I believe more and more that class extension is the only way to build on Nemo).

Inside the code, js and css directories would be serve on every page, which means we they need to be browsed upon init. I threw this base for the code :

def parse_js_and_css_directories(directory, ext="*.js"):
    return {
        filename.replace(directory, ""): filename
        for filename in glob.glob(op.join(directory, "**", ext), recursive=True)
    }

On the other end, I am thinking that statics should be served only upon request (which can help support additional, not on all pages, javascript or css), which I am unsure if it means we need to parse them. Depends on what's easier to work with the plug-in system.

Finally, I really believe it would be great if any of the Nemo deployers can take this issue, and I hope that this survey will be helpful to you.

@PonteIneptique
Copy link
Member Author

I have thought a little more about it :

Plugins should have their additional assets parsed with the same kind of function than quoted up there, same for assets. I think this would make the whole construction easier and it would allow to keep the "update" routine when registering any statics.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants