QuackFuzed [ Ramblings of a Con..ColdFuzed Mind ]

Fusebox 5.5 Implicit Circuit Pathing

Posted on September 13, 2007 at 7:21 PM in Fusebox

The other day Sean released a FB5.5 update to the Cat Club demo application, so I downloaded it to play around a bit with the new toy. I am truly excited about the option to eliminate XML from one's Fusebox applications.

IMPORTANT: The XML is still perfectly valid, and the FB5.5 release will *not* break older apps. As a matter of fact, I have several 5.1 applications that are now running on the 5.5 core, without a single keystroke change to the code.

When I unzipped and ran the Cat Club demo from the webroot, it performed flawlessly. And fast? Yes! Very. "So far so good," I thought, and then I went to putting together my own little demo app, utilizing the implicit circuit feature (no XML). That's when I stubbed my toe, fell down, and skinned up my knees.

I talked with Sean for a good while on my issue, and try as he might, he was unable to duplicate it on his machine. So, I thought I'd throw out this post and see if anyone else runs into the same issue.

Here's what I did: moved the application into a sub-directory of the webroot, and immediately received the following error message:

"Well, you dummy," I mused, "you need to reload the application! Oh, and be sure to parse all!"

Unfortunately, doing so resulted in no change in behavior whatsoever. It seems to me that the Fusebox core is not correctly setting the paths to the application root, and therefore, the paths to the controller / model / view directories are incorrect as well. Here is the controller path that I **think** is being set...

{application_name}/controller/{circuit_name}

Why do I think that? Well, the sample app's name is "ggcc55", and a fuseaction of 'ggcc.home' is being requested - which is the 'ggcc' controller - and the error message indicates that FB is attempting to create a component with a path of 'ggcc55.controller.ggcc'.

So long as I have the files residing in the webroot (D:WebDev in my case) as so...

{webroot}/ggcc55/controller/ggcc

... the application loads without any troubles. Below is a screencap of this directory structure.

Once I move the application files to a lower directory, that's when my troubles arise. Here is the directory structure that I tried to use, below which is a screencap.

{webroot}/ggcc55-2/www

So, my question is, can anyone else duplicate this issue? Or is it just me? I can reliably reproduce the issue on all of my test servers, as well as my production servers.

By the way, I'm running Windoze XP Pro w/ IIS on my test server, and Windoze Server 2003 Standard Edition w/ IIS on my production servers.

Comments

(Comment Moderation is enabled. Your comment will not appear until approved.)

On 9/13/07 at 11:07 PM, Sean Corfield said:

I think when we talked I misunderstood what you were trying to do. With this blog post, I've managed to reproduce the problem. Here's what it is:

You ran the app in /ggcc55 and it generated parsed files. Then you copied the application into the new directory - including the parsed files - and then you tried to run it but it reused the old parsed files which already have ggcc55.controller.ggcc compiled into them. If you delete the parsed files, I think the problem will go away.

Using fusebox.loadclean=true instead of just fusebox.load=true in the URL is a good way to ensure an application starts cleanly.

This only happened because I'd hardcoded the application name. If I'd used the skeleton app as a template, this would not have happened because the application name is derived from the directory path.

Hope that helps?

On 9/15/07 at 9:13 AM, Matt Quackenbush said:

I must still be doing something wrong, because even if I delete all of the parsed files, and append the URL with:

fusebox.loadclean=true
&fusebox.parseall=true
&fusebox.execute=true
&fusebox.password=foo,

I still receive the exact same error message. I will continue to play around with it until I figure out what I'm doing wrong. Whenever I find it, I'll be sure to post the solution.

On 9/15/07 at 1:00 PM, Matt Quackenbush said:

I forgot to mention that I experience the same thing when using the 'noxml' skeleton app.

On 9/26/07 at 8:06 AM, Erik-Jan Jaquet said:

Hi all,

Just wanted to say that I downloaded the beta.0 version, with the noxml skeleton, and that I have the same problems. It can't find the controller, even though I am running directly in the webroot.

Has this been solved by anyone?

Kind regards,

Erik-Jan

On 1/15/08 at 12:57 AM, Sean Corfield said:

This is all very old - can you post an update based on the final, released version of Fusebox 5.5?

On 1/15/08 at 1:25 AM, Matt Quackenbush said:

Sure, I can post an update. This blog post was made over 4 months ago. I was unable to resolve the issue at the time, and have been otherwise too busy with a variety of ColdBox 2.5.1 projects to look at it since then. Quite frankly, I had forgotten that the issue had previously existed for me. When I have the opportunity I'll download the latest 5.5 files and will address it again.

On 1/15/08 at 6:42 PM, Matt Quackenbush said:

I've still not had a chance to do a detailed test, but my initial tests with the latest core release performed flawlessly. :-)

[Add Comment]