lost in a world of events - one handler one webpage?

I've got some basics down already in my third day - RC, SES, plugins,
views and layouts. But I need more help understanding events and their
relation to the layouts/views. From what I understand I have to create
an event handler for each webpage of my website. Plus all events are
handled through the index.cfm. My normal website directory structure
would look like this:
+ business
-----+ overview.cfm
-----+ rules.cfm
+ information
-----+ help-center
-----------+ faqs.cfm
There could be hundreds of nested pages, and i could have 2 or 3
templates. Now in CB it seems that i would need hundreds of event
handlers matching my hundreds of pages. I can't wrap my head around
this. I must be missing something or perhaps i'm missing the purpose
of CB.

Lets say I want to have a folder where I can place html or cfm pages
on the fly where I don't have to create an event handler for these
pages. But these pages do get wrapped with one specific layout. How
can I accomplish this?

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


Kevin S. Anderson
Superlative Solutions, Inc.

@Kevin: Thanks for the login example. Its the next thing I'm going to
look at and I will need some help.