-
Notifications
You must be signed in to change notification settings - Fork 319
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
_template.js usage #464
Comments
?
Meh. I wrote the
Keep consistent with the coding style in it. You can stray from it as need persists. There are enough eyes on new controllers being made that we don't need a huge lists of rules on their creation. So long as it's well written code there's no problem. |
And I appreciate that.
Structure is required with any project... so the "huge" set of rules that you are clearly overly dramatizing isn't as huge as you think. If we didn't need structure we wouldn't have any sort of STYLEGUIDE, CONTRIBUTING and it would all be spaghetti code... so your opinion is notated once again on this... but the DOCs will have something on it. I'm not against removing unused elements but I'm also not for it either... e.g. I'm at 0. Part of the STYLEGUIDE is using braces |
Definition of the word "template":
It's a starting point. Why keep unused code in there, and confuse other developers why a peace of code is not being used and reserves resources. I like the template file as a starting point, but I learn more from existing code which actually does things. Points discussed with my opinion:
|
And I was exactly the opposite on this with the controllers. This is why it is better to describe things for potential newcomers that learn differently. In particular it has been mentioned in #262 that:
... This is still a little vague to me especially since all of you have constantly used the word "controller" when there are what I have recently been calling "handlers" in each "controller" (e.g. I get to convert someones terminology to something that makes sense to me and perhaps others) ... Zren barked at me one time for creating a new controller when that didn't make much sense to take it out of the admin controller... e.g. he wanted a new handler inside of it. Thank you both for your input and I have enough to fill in a short diddy in the Docs when I get around to that. Anyhow |
Are you talking about #318, where you wanted to do a
The Model is the mongoose schema/documents. The View is the Mustache templates. The Controller is the ExpressJS route handlers functions. This is a common pattern with webserver frameworks. We currently bundle a bunch of route handlers in the same javascript module since they manipulate the same Model. Edit: Actually, I'm not quite sure if the "Controller" refers to the file, or the functions themselves. So calling a route handle a controller might be incorrect, but whatever. |
Yes. I don't know if "handler" is the correct nomenclature but it's what I'm using now... I'm open to better terminology because clearly it is lacking a descriptive nature at wikipedia when Jerone presented it the first time months ago... this would have eased some confusion at first back then but we worked it out. |
Which is mostly synonymous with #262 (and open to do preferably incrementally btw save for vote/flag/remove) although this might be interesting with some of the handlers being split up into little pieces filename wise. |
So with the most recent JSHint fixes in #458 ... policy needs to be re/established with not including the defaults in applicable .js...
As I have stated before
aRes
,aReq
,aNext
should always be included... however #458 removes things such astasks
, etc.It is great to optimize however sometimes it's necessary to keep things in for certain backend host provider solutions such as
isPro
,isDev
andisDbg
... e.g. those stay in for #430 and further changes in the backend.As sizzle mentioned sometimes there is a slight derivation from the STYLEGUIDE.md regarding
==
and===
... I do know that the metadata block parsing routine relies on this a bit in the past.Anyhow... the real policy discussion needed now is whether or not to keep existing controllers with nearly the full compliment of what is outlined in the
./controllers/_template.js
.This is team biz because it needs some defining for the DOCs.
The text was updated successfully, but these errors were encountered: