Unusual problem with events and external Views

Communities ColdBox HMVC
1

I am not sure how this is happening, but I know it is something that I am doing I just can’t work out why I get this error message.

First a bit of a background to the solution that I am doing.

When a request comes in, I grab the event and try to find if the event exists and if it doesn’t then I change the event to go to a new event. For example the following URLS, when they come in and there is a common code base then I change to that event.

www.mydomain.com/application1/space

www.mydomain.com/application2/space

Now the way this works is I have handlers for default, and application1 so if the URL for application2 comes in then the event is changed to point to the default/space handler rather than the application2/handler. This works fine up to this point.

The problem arises when application2 has the following

www.mydomain.com/application2/space/spaceURL

I get the following error in the same code, that actually works if I don’t have the spaceURL. The code for this is as follows.

Could not find the included template /views/default/space/displayspace.cfm

var rc = event.getCollection();

var space = Event.getValue(‘spaceURL’,’’);

if(Event.getValue(‘spaceURL’,’’) != ‘’) {

//find space

//if found then display space

} else {

event.setView("/space/displayWelcome");

//display dashboard or welcome screen

}

So if I manually use event.setView() it works as described because the spaceURL is empty, but if it is not then there is no event set and it goes to the default view. But the error message doesn’t make sense, and this is because I have a new Render.cfc which extends the old one in the system core. The reason I do this is because I want the external views checked first, if it exists then it is loaded and if not then it goes back to the default views.

So my question is this, if I can override the Render.cfc why is it not used when the event.setView() is not used?

2

We use a custom Renderer.cfc that extends the regular core one and it
is definitely called when we don't use setView(). We implement a
custom skinning algorithm in our Renderer (that looks in
skins/{siteId} for the view and if not found looks in skins/default
instead. We rarely use setView() since the default selected view is
normally correct (and then passed to our Renderer to look up the
matching skin).

I'm not sure I follow enough of the rest of your email to make a
suggestion. I think I'd need to see more code.

3

Well if I use event.setView(); to the view instead it works fine, remove it
and it errors as there is no view in that location.

This is also the latest from SVn if that helps.

4

I did some further testing and the custom render.cfc is indeed being fired,
the problem is a stupid one on my part.

The reason is that because I changed the event on the fly, it is looking for
the external view in a new location. So when I set the view via
event.setView() it looks in the correct place, and so does the handler when
I don't use it.

Put that down to not paying attention again.

Regards,
Andrew Scott

5

Thanx for the follow-up to close that out.

If it's any consolation, I have a couple of generic events in my
current (large) app and at first those were also firing odd errors due
to similar issues (because of our skinning Renderer.cfc). There are a
*lot* of moving parts in a ColdBox app...

6

Yeah, tell me about it I got caught on this one.

The fix for me as I was changing the event on the fly on each request, was
to bring the event back to the original again for the view rendering.

BTW it sounds like you have written something very similar thing to me, as
this is for a Skin system that I wrote sometime last year. And am now just
modifying it to now, to work with our internal application here.

Regards,
Andrew Scott

7

Our skinning Renderer.cfc overrides just locateLayout() and
locateView() to look in other locations than ColdBox's default.
Essentially we've just added code like this:

    <cfset var cbox_viewPath =
"/#instance.appMapping#/#instance.viewsConvention#/#arguments.view#"
/>
    <cfset var hasSkin = structKeyExists( event, "getSkin") />
    
    <cfif hasSkin and len( event.getSkin() )>
      <cfset cbox_viewpath =
"/#instance.appMapping#/#instance.viewsConvention#/#event.getSkin()#/#arguments.view#"
/>
    </cfif>

    <!--- Check that the current view exists for this skin --->
    <cfif instance.useSkins and hasSkin and
          (event.getSkin() is not instance.defaultSkin) and
          not fileExists(expandPath(cbox_viewpath & ".cfm"))>
      <cfset cbox_viewpath =
"/#instance.appMapping#/#instance.viewsConvention#/#instance.defaultSkin#/#arguments.view#"
/>
    </cfif>

We have site-specific skins and a default skin to fall back on (and if
neither are present, ColdBox's conventions take over).

8

Sean,

That is very similar to what I do, site-specifc then default and then views
convetion. But I also add the complexity that I follow this rule with
handlers as well, which is what threw me out here.

Regards,
Andrew Scott