-
Notifications
You must be signed in to change notification settings - Fork 55
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
add init function #355
add init function #355
Conversation
975b629
to
78ade11
Compare
invenio_theme/shared.py
Outdated
from flask_menu.menu import MenuRoot | ||
|
||
menu = MenuRoot("", None) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from flask_menu.menu import MenuRoot | |
menu = MenuRoot("", None) | |
from flask_menu import Menu | |
menu = MenuRoot("", None) | |
menu_ext = Menu(root=menu) |
major: see https://github.com/inveniosoftware/flask-menu/pull/85/files#r1250872290
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why i need menu_ext
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For consistency with the Flask pattern we're going for tbh... I was even thinking that we could "proxy" the menu.submenu(...)
call using a new Menu.submenu()
method to avoid having to export a MenuNode
object instead of the extension... But this can be easily done also later, once we know that it all works ™️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i personally don't like the Menu.submenu()
approach. It feels like a singleton and i used them to often in the past. in my opinion they produce more problems that they solve.
the menu_ext
will not be used somewhere so it is only to initialize the Menu
on the parsing the python file level?
is it really necessary to initialize Menu
directly? i think i didn't do that somewhere and the tests are all green also on other packages that are using the PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LGTM; some naming changes and consequences from the Flask-Menu
comments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor: we're now establishing a naming convention for these types of "shared extensions" files. I'm aware that we have the same name in invenio-db
, but e.g. the flask-cookiecutter uses extensions.py
.
invenio_theme/shared.py
Outdated
from flask_menu.menu import MenuRoot | ||
|
||
menu = MenuRoot("", None) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For consistency with the Flask pattern we're going for tbh... I was even thinking that we could "proxy" the menu.submenu(...)
call using a new Menu.submenu()
method to avoid having to export a MenuNode
object instead of the extension... But this can be easily done also later, once we know that it all works ™️
invenio_theme/ext.py
Outdated
@@ -81,9 +71,9 @@ def init_app(self, app, **kwargs): | |||
# Register context processor | |||
@app.context_processor | |||
def _theme_icon_ctx_processor(): | |||
from invenio_theme.proxies import current_theme_icons | |||
return {"current_theme_icons": current_theme_icons} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return {"current_theme_icons": current_theme_icons} | |
return { | |
"current_theme_icons": self.icons, | |
"current_menu": menu, | |
} |
- use
self.icons
(since we have it now) - merge the dictionaries (and rename
_theme_icon_ctx_processor()
to_theme_ctx_processors()
- I think
current_menu
is still fine as a name in templates because:- we should try not to break backward compatibility for Jinja template variables
- there is a general convention for prefixing "added" Jinja variables with
current_
. The "current-ness" (i.e. relying on app/request context) is also real, and might e.g. give a hint in case one tries to use it in a non-request template (e.g. email notification template in a Celery task).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i thought i remove the current_
prefix, because the menu is not longer dependent on the context. (yes it was for the icons but it is not true there either, because we removed that part)
current_theme_icons = LocalProxy( | ||
lambda: ThemeIcons( | ||
current_app.config["APP_THEME"], current_app.config["THEME_ICONS"] | ||
) | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
current_theme_icons = LocalProxy( | |
lambda: ThemeIcons( | |
current_app.config["APP_THEME"], current_app.config["THEME_ICONS"] | |
) | |
) | |
current_theme_icons = LocalProxy(lambda: current_app.extensions["theme"].icons) |
assert "THEME_SITENAME" in app.config | ||
|
||
|
||
def test_init_app(app): | ||
"""Initialization.""" | ||
theme = InvenioTheme() | ||
assert theme.menu is None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor: we should assert though that it's there now, even before init_app
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but there exists no more theme.menu
. so we should check against the existence of menu imported from shared.py
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorry, you're right, I was thinking of Menu.root
(see also my correction)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On second thought, I'm not against keeping the InvenioTheme.menu
and InvenioTheme.menu_ext
pointers... The "global" instances in shared.py
are there so that they can be used similarly to from invenio_db import db
. We should still have some hard-connected references though to the InvenioTheme
extension instance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we merge menu
and menu_ext
somehow? invenio-db
uses SQLAlchemy
from flask-sqlalchemy
but does not introduce two global variables. Further i think that menu_ext
is somehow useless. i dont see the use case. i only see the use for
menuand if we use the
register_menudecorator also the
menu` use case is gone too.
e4ea646
to
48a5ee5
Compare
cd57c44
to
0799191
Compare
* breadcrumbs are not longer used in invenio
* the main point of using a shared menu is to have the menu outside of the application context
* current_theme_icons doesn't need the application context anymore
* pytest-black seems out of support. the last commit was from 2020-10-05. Further pytest-black uses a out of date method which mentions pytest>=7.0 with a DeprecationWarning. The simplest solution is to use pytest-black-ng which fixes this situation.
* flask-menu adds current_menu as a context_processor * the current_ is a convention on jinja templates
* to have the blueprints consistently created
0799191
to
64690c3
Compare
NOTE: it works without flask-menu and invenio-base release, BUT it works also if those are released first with flask>=3.0.0