Yes that is the basics of it.
With forms from views, if you take a step back and see it as coming from the client. You will be calling an event and passing all this into the controller anyway.
If you do something like this.
void function search(event, rc, prc) {
writeDump(rc);
writeDump(prc); abort;
}
You will notice that the form fields and any url variables are now store into the RC or the public Request Context, this means that in your controller you can access them via the rc scope anyway. But there are times like form fields such as radio buttons that aren’t passed unless they are actually true.
As with ColdFusion you need to param these so they exist, which sets it to a default value so that anything that request it, wont fail with an undefined error. You could always just place isDefined or structExists, etc. but at the end of the process it is easier to scope it is existence once.
With long files, I can’t stress how important it is to break things down into smaller manageable code. When doing OOP against procedural, it is a big learning curve and mindset to always be thinking now what if what I am writing can be refactored to a general location. Which is why services and models exist in the first place to segregate that logic.
Controllers are no different here, most business logic, if not all should be in models and services at layers that they belong too. By then splitting this all into a view, we remove all the business logic and other code that has no impact on displaying information back to the client application.
Which is the basic principles of an MVC, once you apply that logic to ColdBox you can then see how to begin moving sections of code to their rightful places. Be patient, read the ColdBox documentation not once, not twice but a lot more than you might normally. The reason is that when you begin understanding one aspect of ColdBox other areas start to make more sense if you re-read other sections again.
Hope that helps.
