Cfreport. Controller or View

[David Mineer]

I have a page that uses the <CFREPORT> tag to display a report in .pdf.

 

Now, instead of displaying this particular .pdf to the user in the browser, I want to save it to a file.  No problem there, it does that and just gives me whatever was on the page that contained the cfreport tag.

 

However I want to use <CFREPORT> to create this file, then have it run another page that creates a different .pdf file, then use CFPDF to merge the two.

 

I know how to do all this and it works, but where should I put the <CFREPORT> tag?  Controller, or View?  There will still be instances where I want to return the .pdf to the browser?  I want to be able to do either scenario with the same code.

 

If you say view, a .cfm file, then do I just call those 2 different views in modelglue.xml and then the final "body" view that puts them together and displays or saves them?

--
David Mineer Jr
---------------------
The critical ingredient is getting off your
butt and doing something. It's as simple
as that. A lot of people have ideas, but
there are few who decide to do
something about them now. Not
tomorrow. Not next week. But today.
The true entrepreneur is a doer.

[Jared Rypka-Hauer]

Either, until you figure out why it doesn't belong where you put it
and decide to move it. :)

Once you do, come back and tell us what you did, what you discovered
in the process and what the pain point was that induced you to chance
it. ;)

J

[David Mineer]

Well Said.  I just always do it wrong.  I know, there isn't a right and wrong......

 

Since there is a case where this would have to be in the view (When I just want to return the .pdf to the browser) I figured I would leave it there.  Then, in the event that does all the work to combine them, I just call that view and name it anything other than "body".  Seems to work great.  Now this will have to be done in order or else there won't be any .pdf files to merge, which may be bad because it seems like I have read that relying on order of processing isn't good, but if you need a file to merge, your going to have to create the file first.

 

But I have to remove the 'filename' attribute for it to return to the browser anyway.  Off to see how I am going to handle that.

 

On Wed, Oct 28, 2009 at 3:23 PM, Jared Rypka-Hauer <armcha...@gmail.com> wrote:

Either, until you figure out why it doesn't belong where you put it
and decide to move it. :)

Once you do, come back and tell us what you did, what you discovered
in the process and what the pain point was that induced you to chance
it. ;)

J

On Oct 28, 2009, at 4:13 PM 10/28/09, David Mineer wrote:

[David Mineer]

I was slightly off track in my previous post. It only worked for one event because I was already broadcasting one message that was the same for both events.  When I tried to pull in another it didn't work because that event broadcast a different set of messages.

 

So the solution for me was to create 2 more events. At first I tried just creating one event, createpub, which referenced the other 2 in the <results> section of my event.  In the <views> section I called the page that returns the merged .pdf.  Problem was that whatever was in the last <result> was what got returned.

 

So I created a second event called viewpub.  In this event-handler I simply <include> the view that uses <CFPDF> to merge the 2 files created before and <cfcontent> to display the finished pdf in the browser.  I changed the "createpub" event-handler to have 3 <result> tags which called the 2 events that created the .pdfs and the 3rd one which assembles and displays them.

 

So you call "createpub" (#4) which processes #1, then #2, then lastly does #3 which is show the output (call #4).

 

Hard to explain, but It is working.  Hope this helps someone else.

On Wed, Oct 28, 2009 at 3:37 PM, David Mineer <min...@gmail.com> wrote:

Well Said.  I just always do it wrong.  I know, there isn't a right and wrong......

 

Since there is a case where this would have to be in the view (When I just want to return the .pdf to the browser) I figured I would leave it there.  Then, in the event that does all the work to combine them, I just call that view and name it anything other than "body".  Seems to work great.  Now this will have to be done in order or else there won't be any .pdf files to merge, which may be bad because it seems like I have read that relying on order of processing isn't good, but if you need a file to merge, your going to have to create the file first.

 

But I have to remove the 'filename' attribute for it to return to the browser anyway.  Off to see how I am going to handle that.