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

Consolidate 'search' and 'transfer' into a single Django app #34

Closed
NickolausDS opened this issue May 14, 2018 · 1 comment
Closed

Consolidate 'search' and 'transfer' into a single Django app #34

NickolausDS opened this issue May 14, 2018 · 1 comment
Assignees
Labels
Breaking Change This change is backward incompatible and will require users to edit their portals help wanted Extra attention is needed

Comments

@NickolausDS
Copy link
Collaborator

Originally, I conceived the portal to be composed of smaller standalone apps where developers would pick and choose which app best suited their needs. 'search' and 'transfer' would be completely decoupled apps and contain their own views, models, and templates and could be seamlessly combined with Django URLs. The actual framework turned out very different from that idealized conception.

A 'transfer' app with views and urls doesn't currently exist, as there hasn't been a need for a standalone transfer app. The current 'search' app directly integrates transfer functionality for both Globus Transfer and Preview. While the internal search/transfer components are fully decoupled, the out-of-the-box search portal depends heavily on transfer.

I propose getting rid of both globus_portal_framework.search and globus_portal_framework.transfer and combining them. This would cause breaking changes but make several things cleaner:

  • It would consolidate separate app 'settings.py' files
  • Tests would be simplified due to only referencing a single settings file (e.g. override_settings will work seamlessly again)
  • The directory structure would be simplified, removing a depth layer of directories
  • The two separate utils.py modules would be renamed to more sensical search.py, transfer.py, preview.py modules

This would cause breaking changes for downstream projects that called into apps for specific functionality instead of using the top level includes. For example, from globus_portal_framework.search.utils.default_search_mapper instead of from globus_portal_framework import default_search_mapper

@NickolausDS NickolausDS added help wanted Extra attention is needed Breaking Change This change is backward incompatible and will require users to edit their portals labels May 14, 2018
@NickolausDS NickolausDS mentioned this issue Jun 12, 2018
2 tasks
@NickolausDS NickolausDS self-assigned this Jul 10, 2018
@NickolausDS
Copy link
Collaborator Author

Done in #38

NickolausDS added a commit to NickolausDS/django-globus-portal-framework that referenced this issue Sep 15, 2022
Ians comments, added input/output descs, added copy functionality
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking Change This change is backward incompatible and will require users to edit their portals help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant