CFInclude vs Custom Tag vs CFC for Presentation and Security

Question

I'm just starting out with ColdFusion OOP and I am wanting to make a DIV which shows different links to users depending on what page they are on and what login rights (role) they have. Basically a 'context' menu.

Should I put this toolbar/navigation DIV in a .cfm or .cfc file?

To reiterate; The cfm or cfc file needs to know what page the user is on and will also check what role they have. Depending on these two pieces of information it will display a set of links to the user. The role information comes from the database and stored in a SESSION variable, and to find out what page they are on I guess it could use #GetFileFromPath(GetBaseTemplatePath())#.

My first thought was to have a normal .cfm file, put all the presentation and logic in that file (the HTML and lots of <cfif> statements) to ensure the correct information is displayed in the DIV, and then use <cfinclude> to display it on the page. Then I started thinking maybe I should make a Custom Tag and ask the calling page to pass in the user's credentials and the #GetFileFromPath(GetBaseTemplatePath())# as arguments and then have that Custom Tag return all the presentational data.

Finally I guess a CFC could do the above as well, but I'd be breaking the 'rule' of having presentational and logic data in a CFC.

Any suggestions on the best practice to achieve what I'm trying to do? It will eventually serve thousands of customers so I need to make sure my solution is easy to scale.

Answer 1

Anything that outputs HTML to the screen should be in a .cfm file.

That being said, depending on your need, you could have methods in a CFC that generate HTML, but the method simply returns the HTML as a string.

In programming, there are very few absolutes, but here is one: You should NEVER directly output anything inside of a function or method by using output="true". Instead, whatever content is generated, it should be returned from the method.

If you will have a need to use this display element more than once, a custom tag might be the best way to go rather than an include.

Answer 2

I see security as being a combination of what menu items I can see and what pages can be ran.

The main security function is inside of the main session object

On the menus

I call a function called

if (session.objState.checkSecurity(Section, Item) == 1)
then ...

For page security

function setupRequest() {
  ...
  if (session.objState.checkSecurity(getSection(), getItem()) == 0) {   
    location("#request.self#?message=LoginExpired", "no");  
    return; 
    }
  ...
  }

The particulars of what checkSecurity can do varies from application to application, but it is tied into how FW/1 works. The following security variations exist:

session.objState.checkSecurity(getSection())
session.objState.checkSecurity(getSection(), getItem())
session.objState.checkSecurity(getSection(), getItem(), Identifier)

None of the presentation files know anything about security.

Answer 3

Rules by which I live:) :

No CF business logic in CFM files. Just use some service which will serve template and provide needed data.

navService = com.foobar.services.Navigation(form, url);

and later output #navService.GetNavConent()#

No direct output from CFC files, functions should always return content. For example, make one function which makes one link based on some logic, second which wraps that and returns to cfm template.

Also one more hint, avoid using application and session scopes in your services.

This makes refactoring, testing and debugging too difficult.

For session you can make session.currentUser , CurrentUser.cfc which provides all things you need. e.g. session.currentUser.isAuthorized("backend/administration") and if true, show link to backend/administration.

Same for application, if you need locale, applicaiton wide setting or some singleton, make application.applicationSettings, ApplicationSettings.cfc and use that to retrieve all info you need in cfc's.

These rules will make your application to be easier to test and debug, and really easy to migrate tomorrow on some javascript based UI like Angular or backbone.js since all th edata you need is already in CFC and theoretically you just need to put remote in CFC or make some remote facade in the middle and you're done.