Hi, Daniel:
Like you, I had some "challenges" wrapping my head around the ColdBox
way of doing things. You make some very good points, however, here is a
(potentially over simplified) explanation from my experience:
1. You don't need to have hundreds of handlers. A handler simply equates
to an "event" hence the name "event handler".
2. Within the handler, you would have multiple action method (defined by
CFFUNCTION or public functions if using component script).
3. However, that being said, again you would not need to have hundreds
of methods in your event handler and they could be wired to provide more
than a single function, invoking whatever "view" is appropriate. By way
of example, a system I recently developed has an event handler of
PUBLIC, which is unsecured. Within this event handler, I have a LOGIN
method. Thus the URL would be http://www.example.com/public/login. The
login method, however, has some intelligence built in that determines if
the operation is a GET or POST. If it is a GET, it simply sets the
event.view() to the login view (eg: event.setView("public/login")). If
it is a post, then it gets the form fields from the event structure
(either event.getValue("username") or if I previously did a var
rc=event.getCollection(), it would be rc.username). It would then
process through a model the login logic.
With the above, if the login failed, I insert into the RC scope the
error (exception) structure and reset the view to the login page. The
login view has embedded a helper (renderView("tags/errorDisplay")) that
sense if the error structure exists in the RC, and if so, displays a
formatted error block.
The key, in my development, is to very strictly separate the controller,
model, and view objects. The controller (handler) should do very little
business logic, simply incorporate flow logic. The models are the heavy
lifters, and by using dependency injection, they are just there and can
be easily invoked.
Another very nice feature of CB is the preHandler/postHandler concept,
which can do a lot of stuff for you. In my system, the preHandler
generally sets up any standard RC elements that my views need (for
example, mine always creates a data structure in RC, that I then stuff
value/data objects into).
Coupled with the above is the concept of interceptors, decorators,
plugins and modules you have a very powerful system, out of the box with
very good documentation provided by Luis and the team.
Lastly, as you may have already noticed, this GoogleGroups is amazing as
a source of help and (sometimes overwhelming) information.
Good luck to you in your development efforts. Hope my rambling helps
somewhat.
Cheers!
Kevin S. Anderson
Superlative Solutions, Inc.