search

davidskalinder / mpeds-coder

MPEDS Annotation Interface
MIT License
0 stars 0 forks source link

Decide where to put code so it's usable by both the UI and back-end scripts #127

Closed davidskalinder closed 3 years ago

davidskalinder commented 3 years ago

See https://github.com/davidskalinder/mpeds-coder/issues/122#issuecomment-846282279. Currently generate-coder-table.py can be called from a shell but not from the UI (even though the code works fine, or could with a couple minor tweaks). It's in the project root; some other export scripts that can be run from the shell (and not easily by the UI) are in scripts. And of course the old (now-broken) version of the coder-table export lived in the controller and so could be easily called from the UI but not from a different context.

This stuff should live somewhere so that it can be easily called by the UI controller or by a user. But I don't know where that is in the flask framework. I guess it sounds like a model? But that'd be very different from the just-the-tables-ma'am way we've got the models set up now. It certainly doesn't sound like a view, and it only sounds like part of the controller because our controller is a residual frankencategory that contains everything that we don't know where to put.

@alexhanna, do you have any ideas about this? Is there a clear place in the MVC for stuff like this, or is there a good way of going off the MVC piste to allow functions to be run both by apache/mod-wsgi/flask/controller and by regular shell users?

alexhanna commented 3 years ago

I guess you could turn it into a module and import the workhorse function into the controller. Then just call the workhorse function from main() if you wanted to run it as a script.

On Thu, May 27, 2021, 11:06 davidskalinder @.***> wrote:

See #122 (comment) https://github.com/davidskalinder/mpeds-coder/issues/122#issuecomment-846282279. Currently generate-coder-table.py can be called from a shell but not from the UI (even though the code works fine, or could with a couple minor tweaks). It's in the project root; some other export scripts that can be run from the shell (and not easily by the UI) are in scripts. And of course the old (now-broken) version of the coder-table export lived in the controller and so could be easily called from the UI but not from a different context.

This stuff should live somewhere so that it can be easily called by the UI controller or by a user. But I don't know where that is in the flask framework. I guess it sounds like a model? But that'd be very different from the just-the-tables-ma'am way we've got the models set up now. It certainly doesn't sound like a view, and it only sounds like part of the controller because our controller is a residual frankencategory that contains everything that we don't know where to put.

@alexhanna https://github.com/alexhanna, do you have any ideas about this? Is there a clear place in the MVC for stuff like this, or is there a good way of going off the MVC piste to allow functions to be run both by apache/mod-wsgi/flask/controller and by regular shell users?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/davidskalinder/mpeds-coder/issues/127, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGC6DL4EFNO3YN33WFG3RDTP2C2HANCNFSM45U2CYWA .

davidskalinder commented 3 years ago

Makes sense to me. Is there a good place to put the module(s)?

alexhanna commented 3 years ago

Root seems like as good as a place as any, although I forget the truly Pythonic way of doing it. I know it involves an init.py file in a subfolder.

On Thu, May 27, 2021, 13:37 davidskalinder @.***> wrote:

Makes sense to me. Is there a good place to put the module(s)?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/davidskalinder/mpeds-coder/issues/127#issuecomment-849925163, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGC6DLFZTE53QM55BIZWRLTP2UR7ANCNFSM45U2CYWA .

davidskalinder commented 3 years ago

Hmm, yeah, I worry about root getting cluttered PDQ. There must be some kind of best-practice way to do this in flask? It can't be that every flask application in the world just has all its logic in the controller...

davidskalinder commented 3 years ago

Somehow I feel like this tutorial explains everything except what we actually need to know. And I am again reminded that I neither understand MVCs well enough to know how to structure stuff like this nor can find any good tutorials that teach me how to structure stuff like this.

alexhanna commented 3 years ago

when I was a web developer years ago I think we literally had a folder for each: models, view, controller. so if anything, maybe a new folder for all controllers.

davidskalinder commented 3 years ago

Wait, is this really controller functionality? Maybe my mental image of MVCs is just super controller-light -- I always just think that the job of controllers is just to dispatch info between models, views, and users. But you're the one who's actually studied computers lol.

Anyway, perhaps the coward'spragmatic way out is to create a modules folder and just put it in there? And then if that starts to get busy we can split it up, either into m/v/c subfolders or into folders for each module/component? That would also avoid the awkward situation where we have a top-level controllers folder that mpeds_coder.py isn't in...

davidskalinder commented 3 years ago

Anyway, perhaps the ~coward's~pragmatic way out is to create a modules folder and just put it in there? And then if that starts to get busy we can split it up, either into m/v/c subfolders or into folders for each module/component? That would also avoid the awkward situation where we have a top-level controllers folder that mpeds_coder.py isn't in...

@alexhanna I'm going to interpret your silence as assent... so please speak up to revoke said interpreted assent

alexhanna commented 3 years ago

🤐🤐🤐

On Fri, May 28, 2021, 15:08 davidskalinder @.***> wrote:

Anyway, perhaps the coward'spragmatic way out is to create a modules folder and just put it in there? And then if that starts to get busy we can split it up, either into m/v/c subfolders or into folders for each module/component? That would also avoid the awkward situation where we have a top-level controllers folder that mpeds_coder.py isn't in...

@alexhanna https://github.com/alexhanna I'm going to interpret your silence as assent... so please speak up to revoke said interpreted assent

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/davidskalinder/mpeds-coder/issues/127#issuecomment-850698485, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGC6DK6PYGI2CW73X2VSK3TQAH4TANCNFSM45U2CYWA .

davidskalinder commented 3 years ago

The empty dir is in at f35dd9f215e btw; but I think it shouldn't be merged/PR'd in until there's something in it (which will probably be the result of #122 and/or #124), so I'll leave this issue closed.