issue - using implicit views with noLayout

Here is an issue for me..... I know, I know, you'll say if you want
to use noLayout just set the view, but that won't work for me in the
module I am working on.....

Here is the issue - There is no way to use an implicit view without a
rendering a layout.

The logic in the Renderer plugin only calls implicitViewChecks() from
renderLayout() and if the view has not been explicitly set. The
process of setting the implicit view (the setView function call in
implicitViewChecks() ) will also set a layout in the request context.

Here is a working example.

Inside a handler the only way to set noLayout is to explicitly set the
view:

<!--- Will render the view only --->
  <cffunction name="hello" access="public" returntype="void"
output="false">
    <cfargument name="Event" type="any">

    <cfset event.setView(name = "myHandler/hello", nolayout = true ) />

  </cffunction>

Looking at setView(), the nolayout attribute removes the private
currentLayout value from the request collection so if I try to set
simulate this logic and manually remove the currentLayout, ColdBox
will still render a layout when ColdBox resolves the implicit view.

<!--- this will still render a layout event though I removed the
layout value from the event --->

  <cffunction name="hello" access="public" returntype="void"
output="false">
    <cfargument name="Event" type="any">

    <cfset event.removeValue('currentLayout',true) />

  </cffunction>

The issue is that an empty currentLayout value has multiple meanings
and ColdBox is getting confused. An empty currentLayout value means
not to render a layout, and it also means that the layout should be
resolved when implicitly resolving the view. So I'd recommend adding
an explicit noLayout private event variable similar to NoRender so we
could check absolutely if noLayout has been set.

.brett

Also it appears the defaultView layout setting take precedence over an
implicit view. So if you have a defaultView set you can not use
implicit views. Seems like another bug to me.

.brett

I was looking for something like this the other day, the only solution was
to set the view of the package and handler to the view myself.

This would be a great enhancement that would be lovely to have in the
framework.

Regards,
Andrew Scott
http://www.andyscott.id.au/

From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of Brett
Sent: Tuesday, 14 September 2010 2:33 AM
To: ColdBox Platform
Subject: [coldbox:5765] issue - using implicit views with noLayout

Here is an issue for me..... I know, I know, you'll say if you want
to use noLayout just set the view, but that won't work for me in the

module I

am working on.....

Here is the issue - There is no way to use an implicit view without a

rendering

a layout.

The logic in the Renderer plugin only calls implicitViewChecks() from
renderLayout() and if the view has not been explicitly set. The
process of setting the implicit view (the setView function call in
implicitViewChecks() ) will also set a layout in the request context.

Here is a working example.

Inside a handler the only way to set noLayout is to explicitly set the
view:

<!--- Will render the view only --->
  <cffunction name="hello" access="public" returntype="void"
output="false">
    <cfargument name="Event" type="any">

    <cfset event.setView(name = "myHandler/hello", nolayout =
true ) />

  </cffunction>

Looking at setView(), the nolayout attribute removes the private
currentLayout value from the request collection so if I try to set

simulate this

logic and manually remove the currentLayout, ColdBox will still render a
layout when ColdBox resolves the implicit view.

<!--- this will still render a layout event though I removed the layout

value

from the event --->

  <cffunction name="hello" access="public" returntype="void"
output="false">
    <cfargument name="Event" type="any">

    <cfset event.removeValue('currentLayout',true) />

  </cffunction>

The issue is that an empty currentLayout value has multiple meanings and
ColdBox is getting confused. An empty currentLayout value means not to
render a layout, and it also means that the layout should be resolved when
implicitly resolving the view. So I'd recommend adding an explicit

noLayout

What would you suggest in terms of defaultView and implicit views?

I don't see this as a bug at all, and I think there is nothing wrong with
the way it currently works. The only suggestion that I would make is that we
have a new method we can call something like useNoLayout() or something so
that the implicit view can ignore using a layout if needed.

But the one thing that is confusing to most with implicit and explicit is
that the directories are always different, this is just an observation that
I am sure trips a lot of people up.

Regards,
Andrew Scott
http://www.andyscott.id.au/

Yes, I agree.

I am not a big fan of the implicit views because it makes developers ASSUME that is how it works, the code does not speak to a developer to say what will be rendered. Again, a conventions purist would love this, and I am a conventions lover. But sometimes, having the setView() call seems to me more elegant and documentable.

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

I'd expect that the implicit view would be called before the
defaultView, rather than the way it works now where implicit views
don't work at all if you have a defaultView setting value.

So the order would be:
explicit
implicit
default

@Andrew - why don't you see this as a bug? I do agree we need a
function and/or a setting where we can bypass layout rendering without
calling setView().

I do use setView as a best practice, I just came across this when
putting together an module to test something else.

.brett

Thanks Brett, that makes sense in terms of order of discovery.

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

Now that you have explained it, I am going to agree here.

Regards,
Andrew Scott
http://www.andyscott.id.au/

From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of Brett
Sent: Friday, 24 September 2010 1:36 AM
To: ColdBox Platform
Subject: [coldbox:5882] Re: issue - using implicit views with noLayout

I'd expect that the implicit view would be called before the defaultView,
rather than the way it works now where implicit views don't work at all if

you

I also commited implicit view dispatching, so if an incoming event does not exist but its implicit view does, the view gets dispatched. Try it, pretty cool!

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

Except it doesn’t work in my application.

I have my renderer setup to call the external views location before the standard views location, so if the implicit view exists in the external view location it will not be called as the standard view location is not there.

Question, before I go digging is this easy enough to override so that I can modify it to work in my application?

Regards,

Andrew Scott

http://www.andyscott.id.au/

No idea what you are saying?

Do you need to use this feature? Have you modifyed the renderer?

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

Yes I have modified the rendered, that’s why I am asking is there something special I need to do here to get it to work?

Also is there any reason why the external view can’t be called upon, if it exists use that instead of the standard view, If it doesn’t then use the standard view?

I find this much easier, because I can then allow custom user views to overide the standard views.

Regards,

Andrew Scott

http://www.andyscott.id.au/

Hey Guys -

Did something else change on this? The comment on this check in by
Luis last night implies so:

[Coldbox] Luis Majano committed #1c8b5db17b: The rendering schema is
now: DefaultView setting first, implicit views second. Branch: master

@Andrew - Are you using the ViewsExternalLocation setting? If I am
following you correctly I agree, adding in external view location the
following view lookup order would make the most sense to me

1) explicit external view
2) explicit view based on convention
3) implicit external view
4) implicit view based on convention
5) default view from setting

I think the "internal" view needs to ALWAYS take precedence "external" view. This allows for easy view overrides in the application, but a common set of views in the external location that can be used if one doesn't exist internally.

Make sense?

Curt Gratz
Computer Know How

Yeah makes sense, but I think I am with Andrew on this one.

Allowing an external view to overwrite the views of the internal
application which would be really handy. I'm not sure of the benefit
of having the internal view have precedence.

For example, say I release a coldbox blog application, and you
download it and want to use it. Problem is you don't like the format
of the blog post detail view. With external view taking precedence
you could define a external view location in your coldbox settings and
then copy my blogdetail view into it and modify it to your liking.
With external view precedence your customized view would be rendered
instead of the internal blog detail view without you having to change
any of the core blog app code.

I think Andrew is doing something similar, using client customized
external views.

thoughts?

I do the same thing only the other was around. I like to have applications like blog, etc have all there logic in one place and use them for multiple clients. Then I use the external locations do define those applications(well, now I use them as modules, but the same applies). If I have a client that needs specific customized views, handlers, etc. I create them inside their application.

Seems to make more sense to me as there customizations are local to them.

Curt

No I disagree, if you write an application then I am looking at the normal
view as core code. Then the external view can be used to override the main
view aka re-skin the original.

Regards,
Andrew Scott
http://www.andyscott.id.au/

From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of Curt Gratz
Sent: Tuesday, 28 September 2010 12:35 AM
To: coldbox@googlegroups.com
Subject: RE: [coldbox:5939] Re: issue - using implicit views with noLayout

I think the "internal" view needs to ALWAYS take precedence "external"
view. This allows for easy view overrides in the application, but a

common

set of views in the external location that can be used if one doesn't

exist

internally.

Make sense?

Curt Gratz
Computer Know How

From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of Brett
Sent: Monday, September 27, 2010 9:27 AM
To: ColdBox Platform
Subject: [coldbox:5938] Re: issue - using implicit views with noLayout

Hey Guys -

Did something else change on this? The comment on this check in by Luis

last

night implies so:

[Coldbox] Luis Majano committed #1c8b5db17b: The rendering schema is
now: DefaultView setting first, implicit views second. Branch: master

@Andrew - Are you using the ViewsExternalLocation setting? If I am
following you correctly I agree, adding in external view location the

following

view lookup order would make the most sense to me

1) explicit external view
2) explicit view based on convention
3) implicit external view
4) implicit view based on convention
5) default view from setting

> Yes I have modified the rendered, that's why I am asking is there
> something special I need to do here to get it to work?
>
> Also is there any reason why the external view can't be called upon,
> if it exists use that instead of the standard view, If it doesn't then
> use the standard view?
>
> I find this much easier, because I can then allow custom user views to
> overide the standard views.
>
> Regards,
>
> Andrew Scott
>
> http://www.andyscott.id.au/
>
> From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com]
On
> Behalf Of Luis Majano
> Sent: Monday, 27 September 2010 2:19 PM
> To: coldbox@googlegroups.com
> Subject: Re: [coldbox:5929] Re: issue - using implicit views with
> noLayout
>
> No idea what you are saying?
>
> Do you need to use this feature? Have you modifyed the renderer?
>
> Luis F. Majano
> President
> Ortus Solutions, Corp
>
> ColdBox Platform:http://www.coldbox.org Linked
> In:http://www.linkedin.com/pub/3/731/483
> Blog:http://www.luismajano.com
> IECFUG Manager:http://www.iecfug.com
>
>
> Except it doesn't work in my application.
>
> I have my renderer setup to call the external views location before
> the standard views location, so if the implicit view exists in the
> external view location it will not be called as the standard view

location is

That is exactly what I am doing.

Regards,
Andrew Scott
http://www.andyscott.id.au/

From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of Brett
Sent: Tuesday, 28 September 2010 1:05 AM
To: ColdBox Platform
Subject: [coldbox:5940] Re: issue - using implicit views with noLayout

Yeah makes sense, but I think I am with Andrew on this one.

Allowing an external view to overwrite the views of the internal

application

which would be really handy. I'm not sure of the benefit of having the
internal view have precedence.

For example, say I release a coldbox blog application, and you download it
and want to use it. Problem is you don't like the format of the blog post
detail view. With external view taking precedence you could define a
external view location in your coldbox settings and then copy my

blogdetail

view into it and modify it to your liking.
With external view precedence your customized view would be rendered
instead of the internal blog detail view without you having to change any

of

the core blog app code.

I think Andrew is doing something similar, using client customized

external

This is again why I did it my way, and rewrote the renderer to modify the
external location. This way I can keep a core default look and feel, and by
using the external views location I can then re-skin based on desire and
need.

And I am basically segregating the skin changes from core code. Basically
because internal views is conserved core, external is considered overwriting
the original and not the other way around.

Regards,
Andrew Scott
http://www.andyscott.id.au/

From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of Curt Gratz
Sent: Tuesday, 28 September 2010 1:12 AM
To: coldbox@googlegroups.com
Subject: RE: [coldbox:5941] Re: issue - using implicit views with noLayout

I do the same thing only the other was around. I like to have

applications like

blog, etc have all there logic in one place and use them for multiple

clients.

Then I use the external locations do define those applications(well, now I

use

them as modules, but the same applies). If I have a client that needs

specific