RE: [coldbox:8304] lost in a world of events - one handler one webpage?

Communities ColdBox HMVC
1

I would not create one handler (cfc) for every page. Instead, I would create a handler for each functional area of your site.

Perhaps like so:

Handler: ehGeneral
event: login/ uses view general/vwLogin.cfm

Handler: ehBusniess
event: overview uses view business/vwOverview.cfm

event: rules uses view business/vwRules.cfm

Handler: ehInformation
event: helpCenter uses view information/vwHelpCenter.cfm

event: FAQs uses view information/vwFAQs.cfm

There are no hard rules about where you decide to break up your site. There’s nothing stopping you from creating each of those events (methods) in a single large handler.
Also, it doesn’t have to be one “page” = one event = one view. You can reuse the same view or event for different pages, or run multiple events/views on one page if you have reusable sections in the page.

It’s hard to tell from your example how big your site is. If you really only have 5 pages in it, I would just make one big handler. If you actually have several more pages per “area” and were just simplifying, above structure will probably be a good start. Honestly a lot of your decision might be based on what your event handlers are actually doing. If they are just empty shells that call static views, you could have a generic event handler that set the correct view based on some URL variable and set up some custom routes so it looks pretty. An event actually doesn’t even have to have a view. It can just return data. Lots of options really.

As far as having folders where non-coldbox pages can live-- sure that’s possible, but if you’re wanting those files to also use the same layouts, I would say just make them part of ColdBox and be done with it. There are many other aspects of ColdBox like logging, security, or pretty error handling that I would want to exist everywhere in my site.

Thanks!

~Brad

2

I simplified my structure quite a bit. And thanks for the help - it
certainly makes sense (i'm so glad it does).

Ok, now I'm trying to wrap my head around my expected end result of
having URLs like this one:
Previously: /business/incentives/vacations/overview.cfm
With CB: /business/incentives/vacations/overview
Handler: ehBusiness
event: incentives

I can't think of the rest. unless vacations and overview are handled
like URL parameters then i can determine which view to set. In that
case, this translates to /business/incentives?vacations=overview. And
if I go further with this and expect to have /business/incentives/
vacations/plans/gold this translates to /business/incentives?
vacations=plans&gold= with an empty gold value. So within my
incentives event I would need cfswitch checking for all my cases.

3

By default, with your /business/incentives/vacations/overview, the event would be "business", and the action would be incentives. The additional path_info variables would be parsed as key/value pairs (ei: vacations="overview"). You can easily see this effect if you enable debugMode, then look in the ColdBox Request Structures panel.

You can, however, override this in your /config/routes.cfm file. The default route is:

  Pattern=":handler/:action?"

That means the first is the event handler and the second (optional) is the action. If you wanted to have a section of vacations and page as overview, you could construct the following route (I think) :wink:

  addRoute(pattern=":handler/:action?/:section?/:page?");

Remember, however, that you cannot have required parameters follow optional (designated by the ?). If you had this mapping, then you would end up with the following:

* Event = business
* Action = incentives
* rc.section = "vacations"
* rc.page = "overview"

Your handlers, models, views, etc., could then use these additional optional parameters to modify process flow or render different view.

Kevin