renderPage when views have subfolders

[cbchumley]

Problem: renderPage does not allow routes so how would one accomplish
handling views that have subfolder heirarchy.

Example: admin/users/edit contains my edit.cfm page and from within my
Users controller if i am doing a save and i try to
renderPage(action=edit) it returns an error saying it cant find /views/
users/edit which is correct since its actually one level deeper inside
a folder called admin.

[Chris Peters]

What happens if you do renderPage(action="admin/edit")? A curious little experiment. :)

--
You received this message because you are subscribed to the Google Groups "ColdFusion on Wheels" group.
To post to this group, send email to cfwh...@googlegroups.com.
To unsubscribe from this group, send email to cfwheels+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cfwheels?hl=en.

[cbchumley]

Could not find the included template ../../views/documenttypes/admin/
edit.cfm.

the url looks like this: http://cfcollections.dev/document-types/create
which is the function inside the controller but since my view template
is actually nested inside the admin folder this where the disconnect
happens.

This works fine with routes but once it comes to form interaction and
returning errors when using validation I am unable to get back to the
view with the error message and params.

I can use redirectTo( back="true") just fine but then I lose my params
and the error message.

So close but yet so far :)

On Apr 11, 6:20 pm, Chris Peters <ch...@clearcrystalmedia.com> wrote:
> What happens if you do renderPage(action="admin/edit")? A curious little
> experiment. :)
>

> On Sun, Apr 11, 2010 at 5:07 PM, cbchumley <cbchum...@gmail.com> wrote:
> > Problem:  renderPage does not allow routes so how would one accomplish
> > handling views that have subfolder heirarchy.
>
> > Example: admin/users/edit contains my edit.cfm page and from within my
> > Users controller if i am doing a save and i try to
> > renderPage(action=edit) it returns an error saying it cant find /views/
> > users/edit which is correct since its actually one level deeper inside
> > a folder called admin.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "ColdFusion on Wheels" group.
> > To post to this group, send email to cfwh...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > cfwheels+u...@googlegroups.com<cfwheels%2Bunsu...@googlegroups.com>

[Cathy Shapiro]

cbchumley,

 

Have you tried setting your application.domain in your config/settings.cfm file?

Anytime I'm working in a folder off the root I set this.

 

Cathy

 

To unsubscribe from this group, send email to cfwheels+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/cfwheels?hl=en.

--
Flash Pro Design
4646 Poplar, Suite 517
Memphis, TN 38117

Phone: (901) 767-8767
Fax: (901) 685-9054

http://www.flashprodesign.com

[raulriera]

Have you tried

<cfset renderPage(action="../yourpath")>

When I want to render views from other folders I need to "get out" of
the current controller folder

> > > cfwheels+u...@googlegroups.com<cfwheels%2Bunsubscribe@googlegroups.c om>

[cbchumley]

I wish it was that simple. I can do what everyone suggested very
easily for navigation purposes. The issue once again is that if you
are doing validation inside your model and generate an error that your
capturing in your controller and want to return to the view to expose
the error and retina your params that were submitted by the form you
can't do it by saying renderPage(action="../yourpath") without
returning an error that it can't find the included view. The reason
it cant find it is because its nested inside the admin folder.

Here is the view folder structure
views
--- admin
------documenttypes
-----------index.cfm
-----------edit.cfm
-----------view.cfm

Using routes I can traverse nested views with no problem, using
redirect to I can traverse with no issues using redirecTo(back=true)
however i lose any params that were submitted by the form.

I honestly think the framework needs to be able to allow nested views
and the internal wheels $createControllerClass method modifed to allow
for this. That is my next step to look at but wan't to avoid going
down that path until absolutely necessary.

> > > > cfwheels+u...@googlegroups.com<cfwheels%2Bunsubscr...@googlegroups.c om>

[Andy Bellenie]

I think Raul meant renderPage(template=...)

I use nested views all the time, you shouldn't t need to modify the
framework

Andy

[cbchumley]

Andy would you mind emailing me offline so we can discuss in more
detail.

Cause i have tried everything even including
renderPage(template="...") to no avail.

Would be curious to see how your handling this

On Apr 12, 7:19 am, Andy Bellenie <andybelle...@googlemail.com> wrote:
> I think Raul meant renderPage(template=...)
>
> I use nested views all the time, you shouldn't t need to modify the  
> framework
>
> Andy
>

[cbchumley]

How far nested down do you go. in my example I am not just one level
deep but 2 levels deep. So when you call renderPage(action="edit")
from the DocumentTypes controller the framework naturally assumes you
are looking for a view folder of documenttypes and a template called
edit. Which if the documenttypes folder is nested one level deeper
inside a parent folder of "admin" it won't be ab;e to find it.

Regardless of setting renderPage(action="admin/documenttypes/edit") or
renderPage(template="admin/documenttypes/edit")

Any other suggestions. This is driving me MAD :)

On Apr 12, 7:19 am, Andy Bellenie <andybelle...@googlemail.com> wrote:

> I think Raul meant renderPage(template=...)
>
> I use nested views all the time, you shouldn't t need to modify the  
> framework
>
> Andy
>

[Andy Bellenie]

I use <cfset renderPage(template="/fields/documents/edit")> to call [approot]/views/fields/documents/edit.cfm

To unsubscribe from this group, send email to cfwheels+u...@googlegroups.com.

[raulriera]

Can you tell us from where you are trying to call the action (nested
levels) and how deep is the destination? Show us the full path for
both

[cbchumley]

Alright so getting closer:

Trying to add a record and doing validation this is what i am getting
now:

Controller:
<cffunction name="create">
<cfset documentTypes =
model("documentType").new(params.documentTypes)>

<!--- Verify that the document type creates successfully --->
<cfif documentTypes.save()>
<cfset flashInsert(success="The document type was created
successfully.")>
<cfset redirectTo(action="index") />
<!--- Otherwise --->
<cfelse>
<cfset flashInsert(error=errorMessagesFor("documentTypes"))>
<cfset tabHeading = "Add" />
<cfset formAction = "create" />
<cfset renderPage(template="/admin/documenttypes/edit/") />
</cfif>
</cffunction>

This will return the correct view now - BUT:

1) URL looks like this - http://cfcollections.dev/documenttypes/create
(notice that its not showing cfcollections.dev/admin/documenttypes/
edit)
2) The edit.cfm view has some variables that i set in the create
function of the controller but since renderPage() actually just
displays the view i lose those variables i am setting and am having to
set them in my create function prior to calling the renderPage()

So suggestions on what I need to do to get url to display correctly
and how to get the variables to remain without having to resort to
session variables for them.

BTW - Thanks for everyone's help on this. I will eventually have my
self wrapped around this and will write a series of articles on the
framework at communitymx.com

[raulriera]

The startFormTag() needs the route argument instead of the action
argument..

On Apr 12, 1:44 pm, cbchumley <cbchum...@gmail.com> wrote:
> Alright so getting closer:
>
> Trying to add a record and doing validation this is what i am getting
> now:
>
> Controller:
>         <cffunction name="create">
>                 <cfset documentTypes =
> model("documentType").new(params.documentTypes)>
>
>                 <!--- Verify that the document type creates successfully --->
>                 <cfif documentTypes.save()>
>                         <cfset flashInsert(success="The document type was created
> successfully.")>
>                         <cfset redirectTo(action="index") />
>                 <!--- Otherwise --->
>                 <cfelse>
>                         <cfset flashInsert(error=errorMessagesFor("documentTypes"))>
>                         <cfset tabHeading = "Add" />
>                         <cfset formAction = "create" />
>                         <cfset renderPage(template="/admin/documenttypes/edit/") />
>                 </cfif>
>         </cffunction>
>
> This will return the correct view now - BUT:
>

> 1) URL looks like this -http://cfcollections.dev/documenttypes/create

[cbchumley]

Raul:

so re-reading through the CFWheels document the suggestion is to not
use renderPage() but to use redirectTo() except for when you are
returning errors to the form which is my case.

So if my edit.cfm page is within my admin.documenttypes folder then
how should my route on the startformTag look and how would i then be
able to use the same form for adds and edits (dynamically change the
route)?

Also how do i still handle any variables other than form elements on
the page since method in the controller isnt getting called and they
dont seem to exist anymore when using renderPage().

This seems a lot damn harder than it needs to be.

[Per Djurner]

Ok, you may not like this reply but here it comes anyway :)

I really think you would benefit by sticking to the Wheels conventions until you know the framework really, really well.

What is your reason for wanting more folder levels for views?

To unsubscribe from this group, send email to cfwheels+u...@googlegroups.com.

[Andy Bellenie]

Hiya,

The URL is displaying correctly. You are still within the create function, you are just showing a different view.

Any variables needed for the view will have to be also called in the create function (bad) or created globally for all actions using a filter (good)

To unsubscribe from this group, send email to cfwheels+u...@googlegroups.com.

[cbchumley]

Your right I don't appreciate that answer :) I am marketing the
CFWheels Framework as well using it to rebuild 3 large sites including
one for the Smithsonian so if the capability of what i am trying to do
is not there yet then that is fine. I have the need to have a clean
directory structure based off a SiteMap approach. So if a top level
link is Admin and under that DocumentTypes and under that my templates
for the index, edit, view, etc...

All this seems to work fairly well with Routes and traversing the
views works fine. My only issue is with returning back to a view.

I can take your advice and move back to a single level nesting but I
am not sure that will still fix the issue I am having.

I have read your documentation. I am considered a ColdFusion expert
so I don't beleive its my lack of knowledge with ColdFusion.

Although the site is fairly well documented there are holes in it and
maybe I am just trying to push the framework beyond it desired level.

BTW. These forums are very well maintained and I do appreciate the
answers i have gotten.

I just wish someone had 10 minutes to do a Skype call with me so they
could see what i am working on and then maybe it's just something
simple i am missing.

On Apr 12, 2:30 pm, Per Djurner <per.djur...@gmail.com> wrote:
> Ok, you may not like this reply but here it comes anyway :)
> I really think you would benefit by sticking to the Wheels conventions until
> you know the framework really, really well.
>
> What is your reason for wanting more folder levels for views?
>

> > > > > > > >>>>> cfwheels+u...@googlegroups.com<cfwheels%2Bunsu...@googlegroups.com>

> > <cfwheels
> > > > > > > >>>>> %2Bunsubscr...@googlegroups.c om>
> > > > > > > >>>>> .
> > > > > > > >>>>> For more options, visit this group at
> > > > > > > >>>>>http://groups.google.com/group/cfwheels?hl=en.
>
> > > > > > > > --
> > > > > > > > You received this message because you are subscribed to the
> > Google
> > > > > > > > Groups "ColdFusion on Wheels" group.
> > > > > > > > To post to this group, send email to cfwh...@googlegroups.com
> > .
> > > > > > > > To unsubscribe from this group, send email to

> > cfwheels+u...@googlegroups.com<cfwheels%2Bunsu...@googlegroups.com>

> > > > > > > > .
> > > > > > > > For more options, visit this group athttp://
> > groups.google.com/group/cfwheels?hl=en
> > > > > > > > .
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "ColdFusion on Wheels" group.
> > To post to this group, send email to cfwh...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > cfwheels+u...@googlegroups.com<cfwheels%2Bunsu...@googlegroups.com>

[Andy Bellenie]

cbchumley,

There's no reason at all why you can't use nested views, from the sound of it that's now working.

The other problem you mentioned has no specific solution, depending on the kind of data the view is using there is always a neat way of dealing with it.

You already have the documentTypes model available to that view, so any data that is related to that should come from their. I do my best when designing controllers to create no more than one variable per controller method if possible, and quite often none at all. This makes re-using views a lot easier.

Perhaps you could list the variables you're using in your view and then I can be more specific.

Wheels requires a bit of a philosophical shift from using coding patterns. You get the hang of it very quickly :)

Best,

Andy

To unsubscribe from this group, send email to cfwheels+u...@googlegroups.com.

[raulriera]

Could you please go to "pastie.org" and do a link for?

Your create view
Your routes
Your controller action

> ...
>
> read more »

[cbchumley]

Andy - its sort of working. The view is rendering but the url is not
displaying correctly.

Do you have any examples of how your handling nested views more than
one level deep and how your rendering the view when passing errors
back to the view page that you can send me offline.

I emailed both Chris and Mike but so far your the only one I know that
is using nested views more than one level deep.

On Apr 12, 2:47 pm, Andy Bellenie <andybelle...@googlemail.com> wrote:
> cbchumley,
>
> There's no reason at all why you can't use nested views, from the sound of
> it that's now working.
>
> The other problem you mentioned has no specific solution, depending on the
> kind of data the view is using there is always a neat way of dealing with
> it.
>
> You already have the documentTypes model available to that view, so any data
> that is related to that should come from their. I do my best when designing
> controllers to create no more than one variable per controller method if
> possible, and quite often none at all. This makes re-using views a lot
> easier.
>
> Perhaps you could list the variables you're using in your view and then I
> can be more specific.
>
> Wheels requires a bit of a philosophical shift from using coding patterns.
> You get the hang of it very quickly :)
>
> Best,
> Andy
>

> ...
>
> read more »

[Andy Bellenie]

The URL is displaying correctly. The current controller action is 'create' and that is what the URL is showing. You haven't re-directed anywhere. You are then using renderPage to display the view called 'edit' 

If it's really important that the URL remains the same, then you will have to put some logic into your 'edit' method like this:

<cffunction name="add">

<cfset tabHeading = "Add" />

<cfset formAction = "create" />

<cfif StructKeyExists(params, "documentType")>

<cfset documentTypes = model("documentType").new(params.documentTypes)>

<cfif documentTypes.save()>

<cfset flashInsert(success="The document type was created successfully.")>

<cfset redirectTo(action="index") />

<cfelse>

<cfset flashInsert(error=errorMessagesFor("documentTypes"))>

</cfif>

<cfelse>

<cfset documentTypes = model("documentType").new(params.documentTypes)>

</cfif>

<cfset renderPage(template="/admin/documenttypes/edit/") />

</cffunction>

A few notes though:

The tabHeading variable is the same as your controller action, so why not use that in the view as a default?

<cfparam name="tabHeading" default="#params.action#">

As for the formAction, this depends on whether or not the model is new, so why not create a method in the model like this:

<cffunction name="getFormAction">

<cfif this.isNew()>

<cfreturn "create">

</cfif>

<cfreturn "update">

</cffunction>

Also, you don't need to save the documentType errors into the flash like that. The object is already present so you can just call

#errorMessagesFor("documentType")# in the view.

Hope this helps :)

Andy

--

[Per Djurner]

"I can take your advice and move back to a single level nesting but I am not sure that will still fix the issue I am having."

That's sort of my point actually...

If you stick to the conventions any issues you face will be a lot easier to deal with in isolation (since you won't then also have to deal with the complexity of code added due to breaking the conventions).

You're not the only one wanting to nest controllers and views like this though so it's definitely something we should look into making easier in the framework.

/ Per

To unsubscribe from this group, send email to cfwheels+u...@googlegroups.com.

[cbchumley]

Andy:

Thanks - I hope you dont mind but I emailed you offline

> On 12 April 2010 19:54, cbchumley <cbchum...@gmail.com> wrote:> Andy - its sort of working.  The view is rendering but the url is not

> > cfwheels+u...@googlegroups.com<cfwheels%2Bunsu...@googlegroups.com>

[samarism]

This is off topic and concerns general wheels design principles, but
Andy's comment got my attention:

"I do my best when designing controllers to create no more than one
variable per controller method if possible, and quite often none at
all. This makes re-using views a lot easier."

I did not understand this one variable per controller thing. Do you
mean you wrap all the variables needed by a view into a struct so that
its easy to know which external variables are being used by the view?

Also, I feel it would be really nice to have a document which outlines
general cfwheels design best practices. This forum is like a treasure
trove of such principles but they are all scattered in different
discussions.

Could we have something like a design principle cheat sheet?

On Apr 12, 11:47 pm, Andy Bellenie <andybelle...@googlemail.com>
wrote:

> cbchumley,
>
> There's no reason at all why you can't use nested views, from the sound of
> it that's now working.
>
> The other problem you mentioned has no specific solution, depending on the
> kind of data the view is using there is always a neat way of dealing with
> it.
>
> You already have the documentTypes model available to that view, so any data
> that is related to that should come from their. I do my best when designing
> controllers to create no more than one variable per controller method if
> possible, and quite often none at all. This makes re-using views a lot
> easier.
>
> Perhaps you could list the variables you're using in your view and then I
> can be more specific.
>
> Wheels requires a bit of a philosophical shift from using coding patterns.
> You get the hang of it very quickly :)
>
> Best,
> Andy
>

> ...
>
> read more »

[Andy Bellenie]

That was 1 variable per controller METHOD :)

I think some additional screencasts and sample apps are a great idea,
it's something I'd like to help with as we work towards 1.1 - lots to
do though!

[samarism]

Sorry, I did mean 1 variable per controller method. But, views more
often than not need multiple variables. So, coming back to my
question, do you mean one struct per method?

On Apr 13, 4:40 pm, Andy Bellenie <andybelle...@googlemail.com> wrote:
> That was 1 variable per controller METHOD :)
>
> I think some additional screencasts and sample apps are a great idea,
> it's something I'd like to help with as we work towards 1.1 - lots to
> do though!
>

> ...
>
> read more »

[Andy Bellenie]

A struct doesn't help, that just packages them all together. The point
is not to create them at all. It can require some creative thinking
but often you're using variables instead of methods.

For example, you might need a variable called formAction if you're
using a common edit page for both creates and updates. But instead of
creating a variable in the controller, put a method in teh root model
that returns either 'create' or 'update' depending on whether or not
the model is new.

So formAction now becomes model.formAction()

More often than not the titles etc are the same as your controller
names and methods, so default them that way in a filter.

<cfset pageTitle = Humanize(params.controller) & " - " &
Humanize(params.action)>

and so on.

Don't repeat yourself. If you need to do anything more than once then
there's a good chance you can rationalise it.

[samarism]

Cool! I see what you mean. Having too many variables floating around
does give that uneasy feeling that the code will blow up any time. :)

Thanks for your ideas
:)

On Apr 13, 4:50 pm, Andy Bellenie <andybelle...@googlemail.com> wrote:
> A struct doesn't help, that just packages them all together. The point
> is not to create them at all. It can require some creative thinking
> but often you're using variables instead of methods.
>
> For example, you might need a variable called formAction if you're
> using a common edit page for both creates and updates. But instead of
> creating a variable in the controller, put a method in teh root model
> that returns either 'create' or 'update' depending on whether or not
> the model is new.
>
> So formAction now becomes model.formAction()
>
> More often than not the titles etc are the same as your controller
> names and methods, so default them that way in a filter.
>
> <cfset pageTitle = Humanize(params.controller) & " - " &
> Humanize(params.action)>
>
> and so on.
>
> Don't repeat yourself. If you need to do anything more than once then
> there's a good chance you can rationalise it.
>

> ...
>
> read more »

[Chris Peters]

Would you also say that this is a good case for using filters too? I've become a huge fan of using them to DRY up variables that end up getting set across multiple methods in a controller (or controllers plural).

[samarism]

Chris, could you please give an example of how to use filters to "dry
up" variables. I have no idea what this means.

Thanks :)

On Apr 13, 6:01 pm, Chris Peters <ch...@clearcrystalmedia.com> wrote:
> Would you also say that this is a good case for using filters too? I've
> become a huge fan of using them to DRY up variables that end up getting set
> across multiple methods in a controller (or controllers plural).
>

>  On Tue, Apr 13, 2010 at 7:50 AM, Andy Bellenie <andybelle...@googlemail.com

>
>
>
> > wrote:
> > A struct doesn't help, that just packages them all together. The point
> > is not to create them at all. It can require some creative thinking
> > but often you're using variables instead of methods.
>
> > For example, you might need a variable called formAction if you're
> > using a common edit page for both creates and updates. But instead of
> > creating a variable in the controller, put a method in teh root model
> > that returns either 'create' or 'update' depending on whether or not
> > the model is new.
>
> > So formAction now becomes model.formAction()
>
> > More often than not the titles etc are the same as your controller
> > names and methods, so default them that way in a filter.
>
> > <cfset pageTitle = Humanize(params.controller) & " - " &
> > Humanize(params.action)>
>
> > and so on.
>
> > Don't repeat yourself. If you need to do anything more than once then
> > there's a good chance you can rationalise it.
>

> ...
>
> read more »

[Chris Peters]

For example, in a recent app that I was working on, I added functionality to have params for dateStart and dateEnd. So I have a filter method in controllers/Controller.cfc called setDateRange() that does a number of things. It assigns session values that remember the date range that the user wants to see across page views, sets sensible defaults if nothing is yet stored in the session or passed via params, instances where a value is in fact sent through params, etc.

To apply that logic to actions that need it, I just set the filter in the child init() method, kind of like this:
<cfset filters(through="setDateRange", only="index,indexExcel,expenses,expensesExcel,income,incomeExcel")>

After that filter is run, variables called dateStart and dateEnd are available for the view to use. The view is none the wiser on whether the values came from params, the session, or whatever. And I don't need to manually call setDateRange() from every one of those methods. The behavior in init() takes care of that.

I've also used filters to DRY (Don't Repeat Yourself) up identical values that get set across multiple actions.

The side effect of this is that you end up with an init() method in your controller that is fairly self-documenting. It's much like how models work with associations, validations, properties, etc. You open the file, look at init(), and can get a pretty good idea about what the behavior of the controller is like based on the filters and verifications that are set. And your actions end up being pretty skinny as a result too.

> ...
>
> read more »

[samarism]

Chris, many thanks for the detailed example! I was actually using
something like this in one of my controllers but didn't realize how
important and powerful this technique is. This has added a new
dimension to my controller design outlook.
Excellent stuff!
:)

> ...
>
> read more »