Another CFM page in the root folder?

[Phil Kemp]

Hello all,

In the root folder of my application I and showcasing a "splash" page that will one day live on the old server and point visitors to the new one. When this makes it to production, it will be the only page on the server, but during development, it will live on the same server as the rest of the FW/1 application. And this has led me to find an interesting "feature" of the framework I hope someone can explain:

When I go to my new .cfm file, I am taken to the home page of out FW/1 application.

It seems that FW/1 doesn't care if I go to index.cfm or splash.cfm - it will always take me to the framework, regardless of what .cfm page I actually want.

Can this be turned off so that only requests to index.cfm take me to the framework application and requests to other CFM pages in the root folder return the CFM page requested?

Thanks,

Phil

[Erik Meier]

variables.framework.unhandledPaths - as documented here: https://github.com/framework-one/fw1/wiki/Developing-Applications-Manual#configuring-fw1-applications

--
--
FW/1 on RIAForge: http://fw1.riaforge.org/
 
FW/1 on github: http://github.com/framework-one/fw1
 
FW/1 on Google Groups: http://groups.google.com/group/framework-one
---
You received this message because you are subscribed to the Google Groups "framework-one" group.
To unsubscribe from this group and stop receiving emails from it, send an email to framework-on...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nando Breiter]

I'm not 100% sure if this can be turned off without hacking the framework, but you could simply place the splash page and the new FW/1 app in separate web roots, something like www.mydomain.com and dev.mydomain.com

You could also make your splash page the default page of the FW/1 app and place no navigation on it. The environment control features of FW/1 might also help you to show navigation for the rest of the app on the splash page in a dev environment while hiding the nav in the production environment, or alter what happens when the default page runs ...

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

--

[Phil Kemp]

@ehm77: I can't find out if this works because when I run the reload command via the URL, I still don't see my splash.cfm page - is there another command I need to run?

[Phil Kemp]

@Nando: Does that mean that for each .cfm file I have that isn't part of the Framework, I would need a new instance and FW/1 install? I just want a CFM page that I can call and not have the framework show me the home page of the application - I want it to show me the page I asked for

[Nando Breiter]

Phil, 

I was suggesting a separate webroot without the framework to display an individual .cfm splash page. I don't know what you what to do beyond that to handle what seems to be a transition from the "old server" to the "new server", but it does suggest separate subdomains for the transition period. 

You first said a splash page, but then you seemed to imply there were more ("does that mean for each .cfm file I have that isn't part of the Framework ...")

If you want to mix the old application with the new FW/1 application in the same directory structure, and have them share the same application.cfc and webroot, well, I'm sure there's a way to hack the framework or come up with a weird construction that would make that possible, but to me, that would be a complete mess to work with. I'd do it under duress if you were paying me well, but why bother using an MVC framework if you're going to hack around it? 

FW/1 doesn't allow a willy nilly mix of individual templates and framework calls, for very good reasons. If doing that makes sense to you, I'd encourage you to reconsider your position.

Again, if you simply want to display a splash page that says something like "Coming Soon to a Web Browser Near You!" - you can move the html and any cfml you need from splash.cfm to the default view for the default section, however you define those in the framework settings. You can, for instance define the defaultItem = 'splash' and leave it named splash.cfm, and maybe define the defaultSection = 'transition' - which means you'd create a directory named 'transition' under the views directory and put splash.cfm in there ...  and with those framework settings in place and a reload ...  drum roll ...  you have your splash page in the same webroot as your new FW/1 app. Let it live within your FW/1 app until you are ready to go live with the new app, at which point all you'd have to do is change the framework settings to the final default section and item, push the change to the server, and you're live.

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

[Jared Rypka-Hauer]

+10^10th

Seriously, Phil… just make your splash page the main.default view for the framework and leave it at that… then you’re covered and you don’t have to make this insane mix of stuff…

Or use unhandledPaths… it’s right there waiting for you. ;)

J

On Mar 17, 2014, at 2:45 PM, Nando Breiter <na...@aria-media.com> wrote:

Phil, 

I was suggesting a separate webroot without the framework to display an individual .cfm splash page. I don't know what you what to do beyond that to handle what seems to be a transition from the "old server" to the "new server", but it does suggest separate subdomains for the transition period. 

You first said a splash page, but then you seemed to imply there were more ("does that mean for each .cfm file I have that isn't part of the Framework ...")

If you want to mix the old application with the new FW/1 application in the same directory structure, and have them share the same application.cfc and webroot, well, I'm sure there's a way to hack the framework or come up with a weird construction that would make that possible, but to me, that would be a complete mess to work with. I'd do it under duress if you were paying me well, but why bother using an MVC framework if you're going to hack around it? 

FW/1 doesn't allow a willy nilly mix of individual templates and framework calls, for very good reasons. If doing that makes sense to you, I'd encourage you to reconsider your position.

Again, if you simply want to display a splash page that says something like "Coming Soon to a Web Browser Near You!" - you can move the html and any cfml you need from splash.cfm to the default view for the default section, however you define those in the framework settings. You can, for instance define the defaultItem = 'splash' and leave it named splash.cfm, and maybe define the defaultSection = 'transition' - which means you'd create a directory named 'transition' under the views directory and put splash.cfm in there ...  and with those framework settings in place and a reload ...  drum roll ...  you have your splash page in the same webroot as your new FW/1 app. Let it live within your FW/1 app until you are ready to go live with the new app, at which point all you'd have to do is change the framework settings to the final default section and item, push the change to the server, and you're live.

...

[Phil Kemp]

Maybe I should start again:

I have two CFM pages in my root folder. If I call the index.cfm page, I see my application - great. If I call the other CFM page, I see my application - this is not what I want, I want to be able to see the CFM page I just called.

I get that the unhandledPaths setting can be used, but it isn't exactly what I'm after - if I add a new CFM page, then I'll have to update the configuration file each time. Ideally I would like to set something like "handledPaths=/index.cfm" and be done, but if unhandledPaths is the only way to get this working, then I'll use that.

Except I can't - because when I set "unhandledPaths=/splash.cfm" and call my reload URL parameter, the other settings are all reloaded, but I still can't access my CFM page! What do I need to do in order to get the Framework to pick this change up?

[Phil Kemp]

@Nando - what are these "very good reasons" why having a regular CFM file outside the framework is a bad idea?

[Phil Kemp]

OK, I've sorted it now - turns out that just putting splash.cfm in the unhandledPaths setting was not enough, I needed to put the *full* URL from the root folder, so as this was in a subfolder on our server, I needed to have /folder/splash.cfm

[Nando Breiter]

I'm repeating myself but an MVC framework provides a discipline to follow in the architecture of your code, like drawers for your clothes. That's a good thing, because as a codebase grows in size and complexity, throwing files and functions willy nilly at the problem you are trying to solve is going to result in a much more confusing mess than the room your mother might have yelled at you about. As we code, we sit in the midst of either the organization, or the mess, we create. And it has an effect, I think a large effect, on our ability to think clearly about the problems we are trying to solve. 

Rich Hickey gave an excellent talk some time back: "Simple Made Easy", where he asserts that choosing the easy path in software development, much like leaving your clothes thrown about your room, most often leads to complexity rather than simplicity. Right now it seems easier for you to mix the directories and files of an FW/1 app with standalone templates, but this leads us down a path that ends in complexity - and to me a worse complexity than if you simply create functions and files without any clear organization. If you want to choose "easy", by all means, do so. Learn by experience, we all have. But FW/1 isn't designed to be easy in a throw-your-socks-around-the-room way. It's designed to be simple.

http://www.infoq.com/presentations/Simple-Made-Easy

Another reason: developers often work in teams. If you can throw your socks anywhere in a rather vast building complex and somebody else has to find them, well, that will result in a lot of wasted time and confusion. The confusion of one working outside the discipline of a framework is multiplied if a team is working on a project. So maybe it's a good thing there isn't a "let-me-throw-my-socks-anywhere" setting in FW/1, otherwise the discipline it provides might easily be undermined by a dev that just wants to do their own thing one day.

Another reason: FW/1 not only provides a discipline to organize your code, but also, to some extent, a discipline to organize and handle application state. Say I've got a problem to solve involving a persistently scoped variable in my FW/1 app. I know right off the bat I don't have to go hunting around for it in the view directories, no matter what kind of spaced out day I was having when I first put it somewhere. I also know from the framework itself what cfc's are automatically loaded in application scope when the application starts. That narrows the likely locations down considerably, even if I haven't imposed on myself a clear, straightforward discipline how state should be handled - FW/1 gets me 80 - 90% of the way there, simply by the separation of concerns and the way it's designed. A setting that allows you to mix standalone templates with the framework willy nilly transforms this advantage into chaos. Now I don't know where to look - it could be anywhere, and I might be forced to review each line of code in the whole app until I find the damn thing.

Another reason: the same thing goes for other aspects of my app, model view controller, I know where they all are without having to think about it. This really helps me to focus on the problem at hand rather than getting lost in the incidental complexity an easy-sloppiness would have created.

I'm not saying the difference between simple and easy is black and white - it's a continuum and I'm in a continual process of learning to discern the important difference.

So to sum up, if I may be presumptuous, I think FW/1 is designed to make application development simple, and that's different from easy. Rich's talk says it far better than I ever could.

Nando

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

[Jared Rypka-Hauer]

Phil,

What I still don’t understand is why you can’t just take splash.cfm, rename it “default.cfm” and put it in /views/main… alternatively, leave it named splash.cfm, put it in /views/other and access it via ?action=other.splash…

The whole point of the framework is to, with a little learning curve, make your work infinitely more flexible and easier to maintain in the long run. Why you would want to scatter your codebase with willy-nilly standalone templates is something I cannot for the life of me understand.

So, I get WHAT you want to do. I am asking you WHY you want to do it? If you’re going to do that, why have the framework there at all?

Jared

On Mar 18, 2014, at 4:00 AM, Phil Kemp <boondoc...@gmail.com> wrote:

OK, I've sorted it now - turns out that just putting splash.cfm in the unhandledPaths setting was not enough, I needed to put the *full* URL from the root folder, so as this was in a subfolder on our server, I needed to have /folder/splash.cfm

On Monday, 17 March 2014 13:57:05 UTC+1, Phil Kemp wrote:

Hello all,

...

[Ulf Unger]

Hi Phil, Hi Nando, Hi Jared,

honestly I love FW1 because its so easy to use - for me it was the way to go after Fusebox - I thought... Because there is (beside the pure MVC approach in FW1) a huge difference between FW1 and Fusebox - and thats what Phil has his problems with - and they are real.

Fusbox gave you the easiness of an central controller (even in the latest versions, if you changed the Application.cfc) - FW1 doesn't do that - it put itself in front of all the Coldfusion templates under one Application - and this decision has, like decisions in real life, the typical two sides of a medal. The bright side: It's easier to work together with different developers, but in the dark side it forces you to use the Framwork for every page call.

Sometimes there are circumstances you don't want that. If you just have a application serving the whole website for you - then thats great, but if you're using a content management system and just use an application to do the "interactive stuff", and the rest of the site is build of generated cfml templates out of the CMS, than this behavior is a nightmare. And here you can't compare Fusebox to FW1 anymore...

Although Fusebox is old - it gives you more freedom. It's easier to integrate into ANY CMS (just by using a "cfinclude" to the central controller "index.cfm") - you can't do that with FW1.

Don't get me wrong - for pure application driven sites I love FW1 and I use it a lot for that. For websites based on content management systems I'm still forced to use Fusebox - because I can decide if I want to have the "framework" loaded on every cfml template or just in those templates where I decide to do that.

Honestly I miss this flexibility - because then I could use FW1 for everything - and it would perfectly fit as a framework for small plugins inside of CMS generated cfml templates.

So as you all wrote its not about black and white - sometimes a little gray can life make easier.

Ulf

P.S.: Of course if you use apps inside a CMS you should never ever mix those templates on the same directory level as your app... Why? Because its easier to maintain... Just "include" the framework for those pages you need it...

[Sean Corfield]

On Mar 18, 2014, at 12:28 PM, Ulf Unger <un...@cf-center.de> wrote:
> The bright side: It's easier to work together with different developers, but in the dark side it forces you to use the Framwork for every page call.

That's simply not true. FW/1 can ignore requests to a specific folder or even an individual file (via unhandledPaths) so you can have a folder in the middle of your FW/1 application, that FW/1 simply ignores - and still leverage all of the same application / session scope data. Or you can put a separate Application.cfc in that folder and treat it as a separate application.

> if you're using a content management system and just use an application to do the "interactive stuff", and the rest of the site is build of generated cfml templates out of the CMS, than this behavior is a nightmare. And here you can't compare Fusebox to FW1 anymore...

Indeed you can't compare them because Fusebox isn't lightweight enough to do that - Fusebox makes you choose either/or (as you said in your next paragraph). FW/1 on the other hand is perfectly suited for use as a module alongside a CMS - and Mura has adopted FW/1 as the recommended way to build interactive plugins for it.

I think you're a bit hung up on "include" as the tool to solve all your problems... :)

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Ulf Unger]

Hi Sean,

maybe I need to commit that I'm bit hung up on "include" - because thats the way I implemented it years ago :-)

I thought about a real "dirty" way to do the "include" way like this:

fw1_proxy.cfm (inside /applications/usermanager/):


<cfscript>
request.fw1=createObject("component","Application");
if((structKeyExists(url,"reload") && url.reload=="true") || not structKeyExists(application,"userManager")) {
request.fw1.onApplicationStart();
}
if(not structKeyExists(session,"userManager")) {
request.fw1.onSessionStart();
}
try {
request.fw1.onRequestStart("/applications/usermanager/index.cfm");
request.fw1.onRequest("/applications/usermanager/index.cfm");
request.fw1.onRequestEnd();
} catch (any fw1RequestError) {
request.fw1.onError(fw1RequestError,"");
}
</cfscript>



Application.cfc (inside /applications/usermanager/)

component extends="org.corfield.framework" {

//this.mappings["/userManager"] = getDirectoryFromPath(getCurrentTemplatePath());
//this.name = 'fw1-userManager';

// FW/1 - configuration:
variables.framework = {
base = "/applications/userManager/",
home = "user.default",
trace = false,
applicationKey="userManager"
};

function setupApplication()
{
var beanFactory = new ioc( "/applications/usermanager/model" );
setBeanFactory( beanFactory );
}

function setupSession() {
structInsert(session,variables.framework.applicationKey,structNew(),true);
structInsert(session[variables.framework.applicationKey],"initialized",true);
}

}

And the templates generated by the cms (running in root folder with an Application.cfc to add session management and...) "include" the fw1_proxy.cfm in the specified folder. With this method I got the userManager example from github (2.5RC1) running with only the changes made inside the Applications.cfc...

But I don't think its not a good way.

Any thoughts on how I can add interactive code (like a discussion board, login form...) easily into a cfml template which is generated by a cms? Instead of Mura were using a cms that generates individual, independent cfml files physically on the server out of the database and some parts of those cfml templates should contain a way to "include" interactive stuff delivered by an FW1 app.

I'm open to suggestions.

Greetings

Ulf

[Sean Corfield]

On Mar 18, 2014, at 3:37 PM, Ulf Unger <un...@cf-center.de> wrote:
> I thought about a real "dirty" way to do the "include" way like this:

That's probably not dissimilar to how Blue River implemented the FW/1-based plugin template (you could go download that and take a look). Beware of multiple FW/1 "app" instances running in the same request - they will interfere with each other - and Blue River came up with a solution for that.

There was a FW/1 ticket open for a long time to provide an "include" way instead of Application.cfc but the only people who'd expressed interest in it were Blue River and they solved the problems via their plugin template.

I'd probably solve it via an iframe linking directly to a full-blown standalone FW/1 app, rather than trying to shoehorn FW/1 into an include. Caveat: I've never tried that either (because I've never needed to) so I don't know how successful it would be!

[Tripp Lilley]

On Tue, Mar 18, 2014 at 12:46 PM, Jared Rypka-Hauer
<armcha...@gmail.com> wrote:
> What I still don't understand is why you can't just take splash.cfm, rename

> it "default.cfm" and put it in /views/main...

From O.P.:

"When this makes it to production, it will be the only page on the
server, but during development, it will live on the same server as the
rest of the FW/1 application"

I.e., he wants to throw up a simple, non-FW/1, non-application page to
show people what that simple page is going to look like when it's
deployed entirely outside of the app. The app under development just
happens to live on the same server as the simple page under
development. They are otherwise functionally unrelated. Co-located, if
you will.

- Tripp.

[Sean Corfield]

The simplest solution is to put it in views/test/splash.cfm and then it can be accessed as /test/splash or ?action=test.splash and it just won't care whether the framework runs on not.

When it goes to production (without FW/1) it can live in the root or wherever, but on the dev server (with FW/1) just stick it in a separate views folder and send the link - as shown above - to whoever wants to preview it.

An aside, but related:

If you have a legacy CFML site with just regular .cfm pages in folders and you want, the easiest thing is just to copy the whole site to the new FW/1 views folder and add a rewrite rule so /folder/page.cfm becomes ?action=folder.page or just /folder/page and then everything will continue working - even with FW/1 added.

The only fly in that is if you have files loose in the webroot: you'll have to move those to a specific views folder (say views/root) and update the linked to them - or, again, manage it through rewrite rules on the web server.

That is how I've moved legacy non-framework sites to FW/1.

Sean

[Jared Rypka-Hauer]

Thank you Tripp. I guess my question was poorly worded.

Allow me to revise:

Why not do something like either one of these options?

Create /views/test/splash1.cfm and distribute the URL http://server.com/action=test.splash1

Create /test in the root of the application, drop a minimal Application.cfm in that folder beside splash1.cfm and distribute the URL http://server.com/test/splash1.cfm

Either one would have worked just fine. :)

J

> ...