-
Notifications
You must be signed in to change notification settings - Fork 39
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
Proposal for new project skeleton #75
base: postgres
Are you sure you want to change the base?
Conversation
I don't know what value the |
The meaning of Looks like Imports can be placed in |
yes, I agree. It is only that way just for backwards compatibility, but we can change it to |
Do you mean increase the change for module name clashes? In that case it is always possible for the servant subsite to take the same approach and use an |
This makes sense. The way I broke things out previously was to have |
I like the |
Ok, I agree with squashing If I understand you agree with And what do you thing about module |
I like having a specific module for re-exporting the handlers. The main problem with changing the Handler re-export is what you alluded to: that yesod-bin already has a command to add a handler (which I have never used) which adds an import assuming placing the import into Application. The command will need to maintain compatibility with the previous scaffold. I prefer to to not use plural (Handlers) module names and just stick with the singular (Handler). |
Maybe even The maintaining looks simple: if we did not find module |
|
I cannot say that I favor the |
The question is not about naming this module |
I agree with @wiz. Putting all this
versus
It is about code organisaion. |
I am open to the site prefix idea. I just don't agree that a generic App or Site adds value: it should be specific. |
Specific... like what? Perhaps a better idea would be to skip creating the "HomeR" route/handler and add a |
If you are making a blog app, then |
I think we must stop on some generic prefix, this is the naming issue and user can decide to rename modules later if necessary. Anyway the name of |
It seems like we disagree. The best way forward would be to ask for opinions on the mail list: I will support whatever our users want. |
Can we at least sweep generated code under |
Definitely. I am still planning to merge some of these changes. |
Sweeping the generated code under |
This is related with 997 issue