I wouldn’t mind a feature like that. On the thought of resolving views etc-- after a couple of the E-mail chains this week on the list, I was thinking about asking what people thought of a setting to reverse the local/external lookups for handlers and views. Kind of like how Modules let you decide the lookup order.
Ironic that bots have been screwing with your URLs. I tend to get a few of those errors too. We’ll have a URL that looks like
server.com/index.cfm/handler/action/var/value
and Google bot will hit this:
server.com/index.cfm/handler/action/var/index.cfm
No clue why it decides to add index.cfm in place of my last value…
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Well you think I know how I’d feel about reversing the local/external lookups for handlers and view !
Mike
In a “perfect” world, Brad, I’d also like to be able to nest them. In other words (again, sounding like a broken record) in a SaaS environment there would be a custom “accounts” directory that contains a mimic structure of a CB application directory (handlers, interceptors, views, etc, etc) which would be pointed to (at a request or session level) as the externals so that when the user does
www.mysitecom/home/index
and the account does NOT have any customization, the default handler and view triggers…but if a handler called home that has an event called index exists in the external (specific to the account in request scope), then that triggers instead.
taking it one step further, like you do with super or css, the account specific home/index triggers and, IF REQUESTED, the default one triggers next…though there would have to be some way to distinguish them so that really you could runevent() pretty easily. Just an idea…the former option is better than nothing.
Mike
Brad,
I would be in favour of it as well, and mainly because when I first started using ColdBox 6ish years ago, I thought that was how it was supposed to work.
Now I see Mike has come to the realisation that it doesn’t work the same way, and that’s good to know, only because it is obviously it is not very clear how it currently works.
My perception back then was this.
Normal conventions could be used to provide a basic look and feel, but if you had an application that ran more than website, the external views could be used to provide another look and feel. This was not the case as the standard convention was always loaded first. This was not what I had hoped for, and the only solution was to write an interceptor then to do what I needed, which was to basically change the standard convention on the fly.
Now for backwards comparability, I doubt it would be a huge issue, as I am not sure how many people who use external views would be affected, but I would assume it would be minimal.
And as Mike said you don’t really need my opinion on this change for external views, as I have been very vocal about this problem for 6 years.