Default views that are called regardless of controller?

[Brian Meloche]

In FW/1, that framework has services, controllers, views and layouts
all called when a section and item are called.

eg. localhost/?action=main.default

If there's a main.cfc, it calls a views/main.cfm that corresponds (or
whatever the details are; that's not important).

In LightFront, assuming action = your event/action variable, that's
how it works if there's no main.cfc. If there is a main.cfc, it would
call default() and then default() would have to call a displayView().
It doesn't do it automatically.

Would it be helpful to people if I change it so that it WOULD call
view/main/default.cfm automatically if the main.cfc is present? I am
leaning towards adding this, but I wanted some feedback first.

That's another converging concept between FW/1 and LightFront, but
rest assured, I am thinking of a big addition I haven't announced yet
that would certainly make LightFront go a completely different
direction.

I know the lack of docs beyond what you find in the sample app is a
little frustrating for some. I've been busy on a project using
LightFront that's been taking a lot of my time outside of my day job,
and it's helped me realize a few new features that would really be
awesome if I do implement them and take LightFront in an exciting
direction, but it's still a nacent idea that I won't pursue until
after the project's done. Unfortunately, that also means no docs
either until then, unless someone wants to help me out in that
fashion.

Sincerely,

Brian Meloche,
brianmeloche at gmail dot com
Podcast: cfconversations.com
Blog: brianmeloche.com
Twitter: @coofuushun
Manager, Cleveland CFUG, clevelandcfug.com
Creator, LightFront: http://lightfront.riaforge.org

[Sean Corfield]

On Thu, Dec 31, 2009 at 12:26 PM, Brian Meloche <brianm...@gmail.com> wrote:

In FW/1, that framework has services, controllers, views and layouts
all called when a section and item are called.

eg. localhost/?action=main.default

If there's a main.cfc, it calls a views/main.cfm that corresponds (or
whatever the details are; that's not important).

To clarify: Regardless of whether main.cfc is present, views/main/default.cfm is always executed by FW/1, unless main.cfc:default() causes a redirect of course. 

In LightFront, assuming action = your event/action variable, that's
how it works if there's no main.cfc.  If there is a main.cfc, it would
call default() and then default() would have to call a displayView().
It doesn't do it automatically.

Interesting design choice. ColdBox offers a third choice, just to make up the full gamut: ColdBox requires main.cfc:default() even if it does nothing (and then executes views/main/default.cfm - unless main.cfc:default() selects a different view).

I'll explain the thinking behind my choice and comment on ColdBox's choice because I think it might be useful to folks who want to give Brian feedback (and maybe Brian can explain his thinking too).

First off, I wanted the bare bones default action to be that a simple view is rendered. In the absence of any business logic, the framework should render a matching view. Both FW/1 and LightFront do that.

Second, I wanted the addition of business logic to be purely additive. If you needed something done in order to show a view, you should only need to add the logic - the framework should still execute the view. This is where Brian and I diverged: his choice was that the addition of a controller meant you wanted to take control of the request and therefore it became your responsibility to tell the framework what view to render. It's a very reasonable design choice - just a little different to mine.

ColdBox, on the other hand, is focused on event handling, first and foremost. It requires that you have a handler for every event because it wants you to think about business logic. The views are secondary and, although ColdBox will automatically render a matching view by default, it's easy - and very common in ColdBox - to override the default and tell the framework which view you want it to render.

Migrating a legacy app to all three frameworks is relatively straightforward. You move each legacy page into the appropriate views/section/page.cfm location and update the links to point to section.page events/actions. ColdBox additionally requires that you create handlers/section.cfc for each section containing page() methods for each page (empty initially).

The next step would be to move logic from the pages into the controllers. In FW/1, you'd create controllers/section.cfc as needed and add page() methods as you move each page's logic. In LightFront, you'd do much the same, but you'd add a displayView() call in each page() method as you create it. In ColdBox, you'd move the logic into the matching existing handler method.

Similar process, different details, driven by slightly different design choices.

Would it be helpful to people if I change it so that it WOULD call
view/main/default.cfm automatically if the main.cfc is present?  I am
leaning towards adding this, but I wanted some feedback first.

I'll be interested to see how people vote on this. I can see both sides of the coin.

 

I am thinking of a big addition I haven't announced yet
that would certainly make LightFront go a completely different
direction.

Cool. I look forward to that!

--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood