GnrWebAppHandler: 19 methods with no caller in the framework, to be reviewed for removal or change
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- javascript, python
- Domain
- backend-api-design
Research direction
Start by reviewing the listed methods in gnr/web/gnrwebpage_proxy/apphandler/ and verify their callers, especially rpc_batchDo and dbSelect_selection in application code. For each method, decide whether to keep, change, or remove it, and account for any callers that need migration. The work is done when all nineteen methods have a decision and any affected callers have a disposition.
Written by the indexing model from the issue text.
Description
This is a discussion issue, not a refactoring task: its purpose is to decide, method by method, whether these nineteen are still useful or go.
While building GnrWebAppHandlerNext (#1361) every method of the application handler was checked for callers. Nineteen have none in gnrpy, projects, resources and gnrjs. Sourcerer, which indexes the application repositories, finds callers for two of them. The copy does not carry any of the nineteen; the frozen package still has them all.
Line numbers are of gnr/web/gnrwebpage_proxy/apphandler/ on develop. "Since" is the commit that introduced the method (git log -S); 2009-05-11 is the initial import of the repository, so those methods predate it.
| method | where | since | what it does | callers outside the framework | known defects |
|---|---|---|---|---|---|
getDb, alias __getitem__ |
__init__.py:119 |
2009-05-11 | returns the db; the alias is the DataResolver.__getitem__ protocol |
none | |
_getAppId, property appId |
__init__.py:141 |
2009-05-11 | derives an application id from the request uri | none | self.page.request.uri.split['/'] indexes the method instead of calling it: raises TypeError |
dbSelect_selection |
db_select.py:208 |
2011-10-01 | dbSelect entry point with pre-defined column sets, delegates to dbSelect_default |
dlfgest resources/calcolo_report.py:74 (selectmethod); cusl resources/py_movfilters.py:185, resources/py_pos_utils.py:332 |
|
rpc_getRecordForm |
misc.py:761 |
2009-05-11 | builds a record form | none | calls self.getRecordForm, defined nowhere: raises AttributeError |
formAuto |
misc.py:777 |
2009-05-11 | automatic form from the table columns | none | |
rpc_batchDo |
batch.py:50 |
2009-05-11 | locates a batch class module:Class in the page resources and runs it, optionally forked |
cusl, 11 webpages under webpages/fabbisogni, magazzino, vendite (dataRpc('app.batchDo', batch='batch/...:Class', ...)) |
forked=True does from processing import Process: the module does not exist, ImportError |
runSelectionBatch |
batch.py:121 |
2011-10-01 | runs the batch plugin of a table on a selection, with a thermo callback |
none | the only caller of setThermo |
setThermo |
batch.py:155 |
2009-05-11 | writes batch progress into the page store | none | unreachable once runSelectionBatch is gone |
rpc_getThermo |
batch.py:203 |
2009-05-11 | reads batch progress from the page store | none (no app.getThermo in the client) |
|
rpc_onSelectionDo |
export.py:47 |
2009-06-05 | dispatches a command on a selection to a handler on the page or on the table | none | |
export_standard |
export.py:90 |
2009-06-05 | default export of a selection | none | |
print_standard |
export.py:111 |
2009-06-05 | default print of a selection through common/tpl/standard_print.py |
none (the template docstring names it) | columns is always None |
rpc_pdfmaker |
export.py:136 |
2009-05-11 | renders text to PDF | none | |
rpc_printStaticGridDownload |
export.py:308 |
2009-05-11 | download of a printed static grid | none; the only client reference, genro_grid.js mixin_printData, is commented out |
|
getPackages, rpc_getPackages |
structure.py:44 |
2009-05-11 | list of packages as [name_full, key] |
none (maintenance.py has its own getPackagesBag) |
|
getTables, rpc_getTables |
structure.py:55 |
2009-05-11 | tables of a package | none (the client calls getTablesTree, a different method) |
|
getTableFields, rpc_getTableFields |
structure.py:92 |
2009-05-11 | fields of a table | none | |
_columnsFromStruct |
get_selection.py:781 |
2009-05-11 | columns string from a view structure Bag | none; same code as SelectionProxy.composeStructColumns |
|
_externalQueries |
get_selection.py:525 |
2011-11-27 | merges external store columns into a selection | called by getSelection itself only; same code as SelectionProxy.mergeExternalStoreColumns |
For each method: useful and kept, changed, or removed from the handler. The two with application callers (rpc_batchDo, dbSelect_selection) need a decision on the callers as well: migrate them, or keep the methods with a deprecation warning until they are migrated.
Refs #1354, #1361
- Dominant language
- JavaScript
- Stars
- 8
- Forks
- 4
- Avg merge
- 1d 23h
- Merged PRs (30d)
- 116
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from genropy/genropy
-
refactor task
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 2 days
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 2 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 2 days
-
[BUG] openssl ServiceType declares conf_git, so the openssl service has no default configurationOpenbug
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 2 days
-
bug
Difficulty 2/5 Under an hour Newbie friendliness 74/100
Maintainers usually reply within 2 days
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 2 days
-
good first issue
Difficulty 1/5 Under an hour Newbie friendliness 88/100
saayam-for-all/webapp#1919 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Uuriko/project-room#3728 ·
Maintainers usually reply within 1 day
-
factory-active task-identify-harness-labels-done task-identify-issue-type-done
Difficulty 1/5 Under an hour Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
documentation
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
devops-thiago/ThrillhouseBot#1132 ·
Maintainers usually reply within 1 day