-
Notifications
You must be signed in to change notification settings - Fork 569
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
Minor Homepage enhancements for Nepal #1084
base: master
Are you sure you want to change the base?
Conversation
5abb7d3
to
f6496a8
Compare
controllers/inv.py
Outdated
@@ -1009,6 +1009,11 @@ def set_track_attr(status): | |||
tracktable.recv_bin.writable = True | |||
|
|||
def prep(r): | |||
if r.vars.get("recv.status") == '2': | |||
s3.crud_strings.inv_recv.title_list = T("Existing Shipments to Received") |
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.
"Existing Shipments to Receive"?
I am wary of making this change as it means new strings to translate suddenly.
Especially wary just after Honduras Red Cross spent a long time going through this module & tweaking...perhaps this could go into template?
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.
+1
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.
Although I'm wary about any one template dictating default... Moved to the template for now - but I think that these changes could have generally improved UX with inv
I don't see why we need the SCSS of font-awesome in trunk? We're not going to customize it, are we? |
@@ -0,0 +1,34 @@ | |||
// Animated 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.
We shouldn't really have all this scss in the fonts folder I don't think
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.
+1
PR Updated |
Still a lot of .less files without need. LESS is even /less/ needed than SCSS ;) CSS and font files should be good enough. |
modules/s3/s3query.py
Outdated
@@ -676,7 +676,8 @@ def __init__(self, resource, selector, label=None): | |||
# Fall back to the field label | |||
if label is None: | |||
fname = self.fname | |||
if fname in ["L1", "L2", "L3", "L3", "L4", "L5"]: | |||
# Does this really belong here? Better on gis_location fields |
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.
This does belong here! The labels vary by config location, so the model must be loaded before you can determine which labels to use. Please remove the comment.
Interesting that you say there was no PR - obviously this here is a PR? |
066ed7e
to
28136b0
Compare
@nursix Changes made - how's this look? |
controllers/default.py
Outdated
@@ -63,8 +63,13 @@ def register_validation(form): | |||
|
|||
# ============================================================================= | |||
def index(): | |||
""" Main Home Page """ | |||
|
|||
""" Customized Main Home Page (in modules/<TEMPLATE>/config.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 -1 to introducing this - we already have a (much better) method to customize the home page controller, and this introduces double standards, which is confusing.
But I can see why you did this - you wanted to have access to the IM layout definition.
However, that's not necessary - templates are now just normal modules, so you can move everything into the right place:
- move the IM layout into layouts.py
- move the inv index controller into controllers.py
...and import:
- import IM into controllers.py like: from layouts import IM
- import the inv index controller into config.py like: from controllers import customise_inv_homepage
Alternatively, you can keep the customise_inv_homepage in config.py, and import the IM layout there.
You can even import across templates, e.g. a layout like: from templates.Nepal.layouts import IM
...so there is less need to duplicate code across templates.
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.
Hmmm... (pondering)
I was expecting some debate around this - and generally I'm OK with this approach!
Some comments:
- One main reason to move it into config.py is to avoid restarting web2py for every change!
- We already have double standards with the "customise_home" setting... should that have been introduced?
- I actually see a strong reason for putting more in controllers.py than config.py so that it can be reused between templates - eg, let's say that the customise_org_organization_controller needed to be reused in multiple templates... is this right? (Not something I'm planning to do right away)
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.
Thanks for the import pointers - took <5min to change :)
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.
måndagen den 1 juni 2015 14.50.34 skrev Michael Howden:
@@ -63,8 +63,13 @@ def register_validation(form):
========================================================================
=====>
def index():- """ Main Home Page """
- """ Customized Main Home Page (in modules//config.py) """
Hmmm... (pondering)
I was expecting some debate around this - and generally I'm OK with this
approach! Some comments:
- One main reason to move it into config.py is to avoid restarting web2py
for every change!
This is out-of-date information.All of the template is now imported, so it doesn't make any difference whether
it's config.py or controllers.py. As long as you have module tracking enabled
(debug mode), there's no need to restart web2py.However, note that git repository dates may be older than your .pyc's so that
applying changes with git (e.g. switching branches) may however require a
web2py restart.Also, Eclipse does sometimes not follow these re-imports - even if web2py does
(that's hearsay, though - I'm not using Eclipse).Generally, one should be more relaxed about having to restart web2py - if run
from the command line, it's just two key strokes away, and not really
disruptive for the flow. We can not seriously make code design decisions
dependend on such.
Sorry for the delay with the review, couldn't find the time earlier. Please note that there are merge conflicts, so rebasing may be necessary. |
@nursix Thanks for the review. Everything addressed and merge conflicts resolved (nothing major) - hopefully good to merge! |
281c723
to
8a28bad
Compare
modules/s3/s3codecs/xls.py
Outdated
@@ -171,6 +171,9 @@ def encode(self, data_source, **attr): | |||
list_fields = attr.get("list_fields") | |||
if not list_fields: | |||
list_fields = data_source.list_fields() | |||
# Always export comments field | |||
if "comments" in data_source.fields and "comments" not in list_fields: |
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.
Clear -1 to this - this should definitely not be enforced in the codec, and especially not without any option to turn it off. Exporting comments is not a general requirement for every deployment, and not for every resource either.
There's a lot of non-standard code formatting here still, like blank lines missing where they should be, inconsistent identation (closing brackets), non-standard line breaks, extra whitespace ... If Fran wants to clean it up after merge, then fine - but I actually think you should do that yourself. Enforcing the comments field in the XLS codec is plain wrong - especially without any option to turn it off. And neither can I see why you would remove some of the settings from IFRC/config.py. Regarding the homepage customization patterns - there is a significant difference between the default/index customization and the module index pages: the default/index pattern allows for a multi-page extension, which is very useful for e.g. embedding online documentation. This pattern is by far more powerful and cleaner in view of error handling and forwarding than the customise_xxx_homepage pattern. I am not sure whether the customise_xxx_homepage pattern should have been introduced - to me it always looked like a hack, and not very thought-through. The idea seems ok, but the design is questionable. Especially it does not take into account that errors redirect to the module index (and sometimes even swallows the errors), nor does it consider the implications on permissions. It is also loading functions without need - which is certainly the ugliest part of it (whereas the default/index pattern only ever loads the functions when you actually access default/index). I see this as a rather weak pattern that needs a lot more thought before being applied everywhere. Regarding the re-usability of code across templates: you are /not/ limited to controllers.py in any way. As I said: templates are now regular Python packages, you can have as many modules inside it as you like. You can import from templates.XYZ.config just as much as from templates.XYZ.controllers or templates.XYZ.layouts. However, there are of course "moral" limits - some things don't make sense. For example, importing from a template into core would be stupid, so I would be strict about not allowing that. Nor would I actually want things to get imported from one config.py into another (because that'd pave the road for regression bugs). Generally, we should not strive after maximising cross-template code sharing - if a certain function or class is relevant for many templates, then it should be core. However, there are sometimes two templates within the same general use-case (e.g. RMS and RMS Americas) - and even if they did share certain elements, these elements would still be specific to the case and not necessarily generic. For such cases (derivates and alternatives), it make maintenance a lot easier to import from one template to the other, and helps to maintain consistency. However, I would suggest to move this debate to a more visible forum - it's a bit misplaced on your PR. Note that your PR may take forever if you keep introducing new things into every review iteration - better you just fix/cleanup what you already have in it, and leave the next changes to the next PR. Also note that the more different/independent changes you put into the same PR, the harder it will become to get any of them merged (one-change-blocking-the-other effect). |
07a70b7
to
ac6448e
Compare
Inv * Fix Beneficiary Column on Release Report (=To not From) * Distribution Report * Locations in Filters * Add Staff to Nepal Menu * Use clusters General * If the site is only configed for one country, use the hierarchy for that country * Setting for get_supply_autocomplete * Fix in creating hrm * Fix bug in Inv_send filter * Menu implemented usng S3NavigationItem * Font Awesome 4 added * Remove duplicate "Resource Inventory" menu item * "Resource Inventory" -> "Resources" (KISS) * Fix error in vol * Always add comments field to Excel output * Increase org_organisation.acronym.length to import SBTF Data ("USAID, OFDA, US DoD" = 19)
I've cleaned things up and addressed all comments. If you let me know where there are specific formatting issues I'll address these too. |
@flavour Any delay in merging this? |
No description provided.