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
Default generated Controlers pass params directly to Views #404
Comments
What does your controller look like for the accompanying view? In this example, any given parameters would be directly available to the view
So the issue you mentioned would occur if you had a So here's a better way to do it, you control what items get sent to the view. You can totally remove the params at all if you don't need them.
In this example we put the params inside another object, so you can still use the params if you'd like with the explicit |
The controler I used is the main.js generated by And your answer is exactly what I had in mind and implicitly mentioned by "I don't think it's really an Issue […] And I expect of any decent webdev to know that filtering entries is one of the 101.". The true topic behind this Issue is maybe to tweak a little bit the generator to "by default" offer this kind of wrapping, and no more directly pass the params. Or at least, leaving a big "Don't…" with this thread in the documentation… It depend on how much Geddy want to "pre-patch" the "wanabe-dev"'s numbness. |
Yeah we probably should change the default to wrap the params, good idea. |
Hi,
I'm not sure if it's intended, if "whatever" or what (I'm just a poor newb on Geddy), but the Controlers generated by default pass the params object directly to their "View" //template.
Params object "nearly directly" (there is some escaping) populated by the http lib (GET, POST…).
So let's say I have a jade template like so:
If his url is called with something like:
/?test=ooooooo
There will be a huge "ooooooo" in the h1.
I don't think it's really an Issue, it's mitigated by the fact that the, let's say, "defacer", had to know the exact key.
And I expect of any decent webdev to know that filtering entries is one of the 101.
But maybe this should be kept as a remainder in the "Don't…".
The text was updated successfully, but these errors were encountered: