| Re: sending pdf files to individual email... [message #186438 is a reply to message #186436] |
Tue, 29 July 2014 18:40   |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma:
|
Senior Member |
|
|
Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex(at)attglobal(dot)net> writes:
>> On 7/29/2014 6:40 AM, Ben Bacarisse wrote:
>>> nag <visitnag(at)gmail(dot)com> writes:
>>> <snip>
>>>> I have a text file with employee_number and employee_name and
>>>> employee_email id delimited with comma.
>>>>
>>>> i have uploaded it into a mysql table called empDetails.
>>>
>>> That may not be the best thing to do. For example, if the definitive
>>> source of the data is somewhere else and it's been exported to you to
>>> do this task, putting it into a DB just complicates the process and adds
>>> another point of failure. It does not make the task any easier.
>>>
>>> (Of course, there are lots of cases when it *is* the right thing to do
>>> -- it's impossible to say from what you've said.)
>>
>> Actually, I think it's a pretty logical thing to do. Retrieving data
>> from a SQL database is easier than a .csv file.
>
> I'd say they are pretty much the same, with the DB being a tad more
> fussy if it needs authentication. But I was talking about the work
> flow. I was saying that fopen and an fgetcsv loop is easier than the
> import *plus* the read from DB.
You have to deal with several delimiters and escape sequences in a CSV, but
not in a database. A proper database does not have have empty lines/rows,
which fgetcsv() cannot deal with properly (so you need a gauntlet there).
A good database format has character encoding information attached to the
database, tables and columns, a CSV has not (which manifests itself strongly
if you open UTF-8 CSVs in Excel from Windows Explorer).
A database table column has a type; a CSV has only strings and you need to
convert them. It takes only one function/method call to slurp a whole
database table into an associative array or an array of objects, several to
do that with a CSV.
So I fail to see how CSVs could be easier to process with PHP than a
database query result. Parsing CSVs sometimes is a necessary evil (when
people would not give you access to their database, or you cannot migrate
directly), not something that should be made everyday practice.
> <snip>
>>> [1] http://pear.php.net/package/Mail_Mime
>>> [1] http://pear.php.net/package/Mail
>>
>> Pear's Mail package hasn't been updated in over 4 years and looks to
>> have been abandoned.
<https://github.com/pear/Mail> was last updated 4 _months_ ago. However, if
you cared to visit the site, you would have seen that Mail_Mime, which
matters here, is much more actively developed: “1.8.9 (stable) was released
on 2014-05-14”. And then there is Mail2.
>> I find PHPMailer to be much superior.
I would not debate that at this time.
>> It's available on GitHub.
So are PEAR packages:
< http://blog.pear.php.net/2012/01/24/what-would-you-do-with-5-million-lines- of-code/>
> That looks very good.
>
> I'd always assumed (without any justification) that it was the PHP
> equivalent of CTAN for TeX or Hackage for Haskell -- that most of the
> good stuff would eventually end up there (with some bad stuff that needs
> to be filtered out). Maybe PEAR is administered in some why that puts
> people off, or maybe PHPMailer is a lone example?
They could do a much better job of pointing out that development is going on
on GitHub now. It is hard to find even a link to the PEAR git repository on
pear.php.net. And that double maintenance should cease, too. Maybe it is
an issue of manpower, misorganized personal resources?
--
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]