Re: [ACFUG Discuss] Another CFMAIL Problem

2008-11-10 Thread Ajas Mohammed
Hi,

As per your quote,

then wouldn't it be possible that cfmail could grab the old value from the
SQL Server column (presumably via its 'query=' parameter?) before my SQL
Server update statement stuffs the new value into it?

Well, once you store something, lets say beforeupdate_identColumn.pdf , now
you have a file mapping to identity column. So lets say user changes or
modifies something, then you do update *first* based of identity column.
Then you either create that pdf or send it as an attachment. Makes sense? My
feeling is that once you have anything in DB, you are the master of things.
You can do pretty much anything like update, track changes, come back at
later time and still create docs which might be from way back in time and
what not. Bottom line, you are in control.

Here is simple logic :

step 1. create pdf content variable . I guess you could do this,
cfsavecontent variable=pdfcontenttableblah blah
/table/cfsavecontent

step 2. insert into db. insert into pdf_table(pdf_content) values
('#pdfcontent#') ( what i mean here is to save pdf text with table
formattting etc in the column.

step 3. Now whenever your ready you could
 a. lets say user updates pdfcontent, then you do udpate query first, so you
have latest content.

step 4. get the latest content from the table and
a. create pdf using cfdocument #pdfcontent#/cfdocument or
b. send it as an attachment.

this way you will know for sure, if it was right content or not. Right now
seems to me, its more of guess work and there is no way to make sure you are
sending the so called cache vs updated content.

hope that helps.

Ajas Mohammed.



On Mon, Nov 10, 2008 at 12:23 AM, Dawn Hoagland [EMAIL PROTECTED]wrote:

 IF you can send a link to the server AND he always needs the latest version
 (and assuming it doesn't take long to generate the PDF) - I would send a
 link to a page that generates it on the fly every time and allow him to
 download that version when needed - as previously mentioned by Howard.  This
 eliminates any issues to do with email latency (or the possibility of
 caching) and gives the opportunity to close some security holes created by
 leaving content in an unsecured location.

 Dawn


 On Sun, Nov 9, 2008 at 8:26 PM, Peyton Todd [EMAIL PROTECTED]wrote:

 Doug, your guess that the email gets sent before the new PDF gets built
 rings true to me. It would explain the problem on my client's server, as
 well as the fact that it's not happening to me right now testing the system
 working on my own PC as localhost. It jogs my memory that my coworker
 experienced a similar problem back about 2001, when I was programming
 ColdFusion in New York City. (?New York City!?? Get a rope!)

 Dean, doesn't it make sense to you that the e-mail could get sent before
 the second version of the file gets built, so it merely picks up what it
 finds on the disk , namely, the earlier version of the file? Actually, come
 to think of it, that would not be an instance of caching.

 Ajas, I don't know, but it seems to me that saving the PDF into a SQL
 Server column might have the same problem as that described by Doug: if
 these operations can be performed asynchronously, then wouldn't it be
 possible that cfmail could grab the old value from the SQL Server column
 (presumably via its 'query=' parameter?) before my SQL Server update
 statement stuffs the new value into it?

 Howard, No, I didn't mean the office manager might get mixed up on which
 file is which - he's reasonably computer literate, and knows perfectly well
 that the one on top was sent later (Whoops! It just occurred to me that that
 might not always be true if there's a glitch in the e-mail process...).
 Anyway, though, what I did mean is that it's simply the older version of the
 file that gets attached to the e-mail. Your idea of sending a link seems
 like a good one, and I may try that but ...

  Naming the PDF by the Job Number instead of by the reporter's ID is
 necessary of regardless of whether I attach the file or send a link. In
 either case, I'd be writing the file to disk. If I were to delete any old
 copy beforehand, what are the chances that (if this asynchrous story is
 true) cfmail would fail to find the file when it looks for it and throw an
 error?

 Peyton

 -Original Message-
 From: Howard Fore
 Sent: Nov 8, 2008 8:12 PM
 To: discussion@acfug.org
 Subject: Re: [ACFUG Discuss] Another CFMAIL Problem

 I think what he means is that if a recorder creates a file and sends it,
 then corrects it and sends again, the recipient could open the first one and
 think it is the most current version when it isn't. It wasn't identified as
 an issue by Peyton but I could see how it could cause someone an issue. My
 response to that would be to not mail the PDF as an attachment but rather
 email a link to the user. The link would either lead to a real PDF, stored
 on disk, or to a CFM file that generates the PDF when it is requested. That
 would get rid of any caching 

[ACFUG Discuss] CF 8 Dynamic PDFs

2008-11-10 Thread Brett Bruschke
I have just discovered the benefit of PDF Forms in CF 8.  However, I  
have one small dilemma.  Is there a way to generate a static PDF from  
a dynamic PDF Form?


In other words, I have a several Word documents that together make up  
a contract that we send out to our clients.  Currently, our Contract  
Administrator opens the Word contract template and modifies the client  
name, client address, client phone number, . . . . etc each time she  
needs to create a new contract.


I wanted to make this process more automated, especially since we  
already have all the client data in our database.  So, I converted  
these documents to PDF Forms from Word Docs using Live Designer.  I  
figured this was they best approach so that as the contract forms  
require changes (which occurs every 6 months or so) anyone could go in  
and change the basic content of the text fields in Live Designer (as  
opposed to creating the contract docs in a .cfm page and using  
CFDOCUMENT to create the PDF, which would require someone to have to  
make sense of HTML and all other stuff that I would include in a .cfm  
page to allow for proper formatting).


The benefit to me is that I was then able to include floating fields  
so that our Contract Administrator no longer needs to manually modify  
the client information for each contract.  Now she can select the  
client from a drop down and click a button to generate the contract.


Only some of the pages in our contract require customization for each  
client.  Other pages are identical for all clients.  The problem I  
have having is that when I use cfpdf action=merge to pull together the  
static PDF files and the dynamically created PDF Forms the final PDF  
document only ends up containing the website created PDF Form.  The  
other static PDF documents just seems to not be merged.  I thought if  
I could somehow tell the CFPDFFORM tag to create a static PDF Form  
without any embedded or attached data then the merging would be  
successful.


Any suggestions would be much appreciated.  (I hope this makes sense,  
and I also am sorry for the long question)



-
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform


For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-





Re: [ACFUG Discuss] Another CFMAIL Problem

2008-11-10 Thread Peyton Todd
I was at my client's site today, and adopted the easiest solution, which was: (a) writing the PDFs to a directory outside the web root and reading them from there; (b) naming the PDFs with the job number instead of the reporter's initials; and (c) deleting any existing PDF by that name before the process begins (except in one rare, non-mission-critical situation, where, as a test, I decided to wait and see if it bites me).Ajas, assuming that I delete any PDF by the same name before I begin, your scenario of writing any change PDF content to a database and building the PDF from there only after the updates to the database are performed does solve the problem I posed to you, but I still have a question regarding your step 4, which I repeat below for ease of reference: step 4. get the latest content from the table anda. create pdf using cfdocument #pdfcontent#/cfdocument orb. send it as an attachment.My question: If I create the PDF from the saved data column, and if the root cause is caching (which remains theoretical), couldn't cfemail still simply go with the cached copy in cases where the same job number is being updated? Yes, one would suppose that deleting the file would have led a smart cache-management program to clear its namesake from the cache, but then a smart cache-management program ought to have known better than to go with the cached copy of a PDF which gets re-written directly, without the intermediary of a database, should it not? (Keeping in mind - I say again - that the caching explanation may be false anyway.)Dawn, my page already re-generates the PDF every time on the fly. But maybe I don't understand your comment: since you say it patches the security hole, is it your idea that the PDF never gets written to disk? Howard, if I were to sent the office manager a link to the PDF instead of attaching the PDF to his email, how would I do that? Now that I am writing the PDFs to a directory outside the web root, how could a link reach that directory? And if I continue to place the PDFs in a subdirectory of the web root, how could I secure it? Doug and Dean, have either of you convinced the other that either the caching theory or the asynchronous theory could be correct, or that neither could be? If the problem goes away, then of course it's academic. But since I'm an academic myself...PeytonP.S. Believe me, I'm not making all this up. The problem is a real one. The solution I put in today means this problem would now occur - if it does still occur - only in the rare case when a reporter sends a job report and soon afterwards corrects it and sends it again, as opposed to the frequent case where the reporter reports two different jobs one after the other.-Original Message-
From: Ajas Mohammed <[EMAIL PROTECTED]>
Sent: Nov 10, 2008 9:20 AM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] Another CFMAIL Problem

Hi,As per your quote, then wouldn't it be possible that cfmail could grab the old value from
the SQL Server column (presumably via its 'query=' parameter?) before
my SQL Server update statement stuffs the new value into it?Well, once you store something, lets say beforeupdate_identColumn.pdf , now you have a file mapping to identity column. So lets say user changes or modifies something, then you do update *first* based of identity column. Then you either create that pdf or send it as an attachment. Makes sense? My feeling is that once you have anything in DB, you are the master of things. You can do pretty much anything like update, track changes, come back at later time and still create docs which might be from way back in time and what not. Bottom line, you are in control.
Here is simple logic :step 1. create pdf content variable . I guess you could do this, cfsavecontent variable="pdfcontent"tableblah blah /table/cfsavecontentstep 2. insert into db. insert into pdf_table(pdf_content) values ('#pdfcontent#') ( what i mean here is to save pdf text with table formattting etc in the column.
step 3. Now whenever your ready you could a. lets say user updates pdfcontent, then you do udpate query first, so you have latest content.step 4. get the latest content from the table and a. create pdf using cfdocument #pdfcontent#/cfdocument or 
b. send it as an attachment.this way you will know for sure, if it was right content or not. Right now seems to me, its more of guess work and there is no way to make sure you are sending the so called cache vs updated content.
hope that helps.Ajas Mohammed.On Mon, Nov 10, 2008 at 12:23 AM, Dawn Hoagland [EMAIL PROTECTED] wrote:
IF you can send a link to the server AND he always needs the latest version (and assuming it doesn't take long to generate the PDF) - I would send a link to a page that generates it on the fly every time and allow him to download that version when needed - as previously mentioned by Howard. This eliminates any issues to do with email latency (or the possibility of caching) and gives the opportunity to close some security 

Re: [ACFUG Discuss] Another CFMAIL Problem

2008-11-10 Thread Douglas Knudsen
There are certainly many ways to skin this cat.  I would not trust your
original approach from bad experiences in the past.  THings may have
changed.  Hey, things have changed!  CFMail in CF8 has ability to delete
attachments after being sent???

 Here is a fairly recent thread on this topic
http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54028  There
are some links in there discussing inline attachments either using CFMail or
dropping to Java mail.

inline attachments, no file saving needed at all
http://blog.pengoworks.com/index.cfm/2007/10/26/Using-CFMAIL-to-send-attachments-stored-in-memory

HTH

Douglas Knudsen
http://www.cubicleman.com
this is my signature, like it?


On Mon, Nov 10, 2008 at 9:29 PM, Peyton Todd [EMAIL PROTECTED]wrote:

 I was at my client's site today, and adopted the easiest solution, which
 was: (a) writing the PDFs to a directory outside the web root and reading
 them from there; (b) naming the PDFs with the job number instead of the
 reporter's initials; and (c) deleting any existing PDF by that name before
 the process begins (except in one rare, non-mission-critical situation,
 where, as a test, I decided to wait and see if it bites me).

 Ajas, assuming that I delete any PDF by the same name before I begin, your
 scenario of writing any change PDF content to a database and building the
 PDF from there only after the updates to the database are performed does
 solve the problem I posed to you, but I still have a question regarding your
 step 4, which I repeat below for ease of reference:

 step 4. get the latest content from the table and
 a. create pdf using cfdocument #pdfcontent#/cfdocument or
 b. send it as an attachment.

 My question: If I create the PDF from the saved data column, and if the
 root cause is caching (which remains theoretical), couldn't cfemail still
 simply go with the cached copy in cases where the same job number is being
 updated? Yes, one would suppose that deleting the file would have led a
 smart cache-management program to clear its namesake from the cache, but
 then a smart cache-management program ought to have known better than to go
 with the cached copy of a PDF which gets re-written directly,  without the
 intermediary of a database, should it not? (Keeping in mind - I say again -
 that the caching explanation may be false anyway.)

 Dawn, my page already re-generates the PDF every time on the fly. But maybe
 I don't understand your comment: since you say it patches the security hole,
 is it your idea that the PDF never gets written to disk?

 Howard, if I were to sent the office manager a link to the PDF instead of
 attaching the PDF to his email, how would I do that? Now that I am writing
 the PDFs to a directory outside the web root, how could a link reach that
 directory? And if I continue to place the PDFs in a subdirectory of the web
 root, how could I secure it?

 Doug and Dean, have either of you convinced the other that either the
 caching theory or the asynchronous theory could be correct, or that neither
 could be? If the problem goes away, then of course it's academic. But since
 I'm an academic myself...

 Peyton

 P.S. Believe me, I'm not making all this up. The problem is a real one. The
 solution I put in today means this problem would now occur - if it does
 still occur - only in the rare case when a reporter sends a job report and
 soon afterwards corrects it and sends it again, as opposed to the frequent
 case where the reporter reports two different jobs one after the other.



 -Original Message-
 From: Ajas Mohammed
 Sent: Nov 10, 2008 9:20 AM
 To: discussion@acfug.org
 Subject: Re: [ACFUG Discuss] Another CFMAIL Problem

 Hi,

 As per your quote,

 then wouldn't it be possible that cfmail could grab the old value from the
 SQL Server column (presumably via its 'query=' parameter?) before my SQL
 Server update statement stuffs the new value into it?

 Well, once you store something, lets say beforeupdate_identColumn.pdf , now
 you have a file mapping to identity column. So lets say user changes or
 modifies something, then you do update *first* based of identity column.
 Then you either create that pdf or send it as an attachment. Makes sense? My
 feeling is that once you have anything in DB, you are the master of things.
 You can do pretty much anything like update, track changes, come back at
 later time and still create docs which might be from way back in time and
 what not. Bottom line, you are in control.

 Here is simple logic :

 step 1. create pdf content variable . I guess you could do this,
 cfsavecontent variable=pdfcontenttableblah blah
 /table/cfsavecontent

 step 2. insert into db. insert into pdf_table(pdf_content) values
 ('#pdfcontent#') ( what i mean here is to save pdf text with table
 formattting etc in the column.

 step 3. Now whenever your ready you could
  a. lets say user updates pdfcontent, then you do udpate query first, so
 you have latest content.

 step 4. get the 

Re: [ACFUG Discuss] Another CFMAIL Problem

2008-11-10 Thread Howard Fore
On Mon, Nov 10, 2008 at 9:29 PM, Peyton Todd [EMAIL PROTECTED]wrote:

 Howard, if I were to sent the office manager a link to the PDF instead of
 attaching the PDF to his email, how would I do that? Now that I am writing
 the PDFs to a directory outside the web root, how could a link reach that
 directory? And if I continue to place the PDFs in a subdirectory of the web
 root, how could I secure it?


What I would do is not generate the PDF until requested. That is, email the
user a link to a CFM page that compiles the PDF from db and returns it to
the user. Alternately if there is a business requirement that the PDF
actually exist on disk, put it a place outside the webroot and use the
cfcontent tag to serve it up via the link in the email.


-- 
Howard Fore, [EMAIL PROTECTED]
The universe tends toward maximum irony. Don't push it. - Jeff Atwood



-
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-