When will you do a rewrite to move from Applicatin.cmf to Application.cfc?

Hey Ray,

Does this build include the updated Lyla Captcha, or will wee need to apply that ourselves?

It is. Forgot to mention it above, but it is mentioned in the readme.

@Gary,

Wouldn't making a switch to Application.cfc alienate all folks using earlier versions of CFMX? Why would that be a good thing? What advantages would switching from Application.cfm to Application.cfc achieve? Can you tell that I'm still running MX6.1? ;o)

Chris

Gary, Christopher is right. I've got far too many people on CF6. App.cfc IS nicer, trust me, but I'd lose a lot of users if I did this.

@Chrustopher: Thanks for the comment. I hadn't thought of that when I asked the question.

@Ray: Thanks for the answer. I thought there must be a good answer.

Ray,

Could you explain why you don't use WYSIWGY for message on blogcfc?

Thanks

I'm trying to limit the number of external apps I ship with blogcfc. I did make it easier to use RTE with BlogCFC though.

Hi Raymond,
Great work on blogCFC. Anyways, I'm trying to get one of our projects to use blogCFC as the blog engine over wordpress, primarily because we are mostly a CF development team. The business owner has a few concerns I was hoping you could answer.
- Virtually all BlogCFC sites look identical. Skinning seems to be extremely limited.
- Limited plugins
- Does not support multiple categories
- Does not seem to play well with standard embeddables (Slideshare, YouTube, GCast)
- So far as I could see, does not seem well suited to maintaining large numbers of blogs (We have the potential to put up a few thousand blogs in a very short time-frame)
- No migration path in place from Typepad to BlogCFC

Any help would be greatly appreciated!
Thanks,
Rob

Let me address each one:

1) Yes, I don't have many skins out there. I ship with a few alternate CSS skins, but in general, if you want something different, you have to do it yourself. I do try to make this easy, and I'd say only about half of the BlogCFC installs use the default. I'd bet most of those half are folks who didn't get up on customizing, but just didn't really care.

2) Limited Plugins: What exactly do you mean by plugins?

3) It _does_ support multiple categories. Has for a very long time. :)

4) You can embed any HTML you want into an entry. Do you have a specific example of something you couldn't embed.

5) Sorry - but this is a bit vague. BlogCFC supports multiple blogs in one db, multiple blogs in multiple dbs, multiple client installs, or even "Blogger.com" style installs. A few people have hundreds of blogs running.

6) Yep. No migration. But I'm sure you could write a simple import script (and then contribute back to the project :)

@Ray.... You do not need to alienate all your users to use Application.cfc, you can include the 2 files in your distribution. Those who do not have cfmx7+, coldfusion will only load and use Application.cfm and for those who are using CFMX7+ when running the application coldfusion will load Application.cfc first and ignore Application.cfm.

HTH

@Ray.... Btw you want to talk about alienating your users, I would prefer to see the config files in an xml based config file rather than using the profile settings of the ini file.

There are a huge amount of hosting providers out there that switch that function of for security reasons, and that means that I have to take the time to modify the code each and every release to get your blog to work on a hosting provider.

Per your first comment - while I could do that - I do not want to add twice the work. It is only one file - but still, any bug I fix in one I have to fix in the other. It also means I could forget to fix something in one file that I fix in the other.

As for your second comment - I'd be willing to bet more ISPs block cffile as opposed to those who block the INI functions.

@Ray,

Hmmm... your missing the point of Code Reuse, did you not think that one could create a library for use to the Application settings then use the appropriate Application.xxx to load and setup?

That way change one, change all:-)

As for second comment, I doubt it very much I have not come across one hosting provider that has cffile switched off for the reason of MVC frameworks all now use xml based configuration. And they know that they will alienate themselves if they where to not provide this feature, besides it is better sandboxed that the profile settings.

But for some reason profile settings seems to be a different when they sandbox the servers.

Errr - so I should build an abstract settings thingy and have app.cfm or app.cfc use it? I don't think that really makes sense honestly. I'll have to disagree here.

Well, if I use one or the other, folks are going to have to deal I guess. I have not yet had any (afaik) requests to switch away from the INI file setup.

@Andrew,

Who's your host? I'm with CrystalTech, and have no problems with the INI file setup. I think if there were a real problem with it, there'd be a lot more people complaining about it.

I used to have Viux as my host, and they had problems with access to CFFile and CFDirectory, but I was on some kind of grandfathered account that they'd done away with. All their new accounts were given access to these two commands. Also, they were slowly but surely migrating all of their older account holders over to the new way of doing things. I left them for other reasons honestly.

As for the Application.cfm vs. Application.cfc is concerned, I don't see the point. Application.cfm already works just fine. It seems to me that if Ray were to write it to use one or the other based on which version of CF the client was running, that it would just be more work for him with little gain. Then again, I've not used Application.cfc, so I don't really understand the benefits that it brings. My client still uses MX6.1 so I've not had the opportunity. :o(

Anyhoo, thems my thoughts. :o)

One point Christopher - App.cfm does work fine, BUT, in all other cases I'd urge folks to use App.cfc. It is more powerful and is really the most recommended thing to do. Again - my case is different since I'm supporting both platforms. I may consider dropping CF6 support when CF9 comes out.

@Ray,

I understand that your case here is special, and while I don't really want to turn this into an article on App.cfm vs. App.cfc, could you briefly explain what advantages App.cfc has over App.cfm?

Simpler handling of events. So for example, in the past to set application variables once, you had to use a 'marker' variable:

if not isdefined app.foo
set....
end if

Now you can just use onApplicationStart. Ditto for onSessionStart.

Plus you get the ability to run stuff when sessions/apps die.

I find it makes the code a lot cleaner too.

Thanks for taking the time Ray. I appreciate it. Perhaps, I'll get to use it some time in the future.

Here's a request to move away from the INI file setup :)

Now you can't say that you did not have any requests :)

Seriously - I think that in this day and age it's far easier to get a host to allow the use of cffile over set-/getProfileString.

I just had an experience with it my self, and judging by the comments I' not alone: http://trond.ulseth.no/inde...

Well, I won't promise anything but I'll think about it for 6.0.

LOL, if a host allows cffile and disables getprofilestring then you need to change hosts pretty quick as they don't have a clue and are insecure.
If they use sandboxes then neither cffile or getprofilestring are a problem and there is no reason to disable either.
But why would you need CFFILE anyway just to read an XML file? Cfinclude works fine.