php-general Digest 11 Dec 2010 01:37:02 -0000 Issue 7080
Topics (messages 309949 through 309960):
Re: ORM doctrine
309949 by: Robert Cummings
309951 by: Lester Caine
309952 by: tedd
309953 by: Tommy Pham
309954 by: Joshua Kehn
309955 by: larry.garfieldtech.com
309956 by: Robert Cummings
309958 by: David Harkness
Re: No errors gets displayed, just a blank page
309950 by: tedd
Re: A general discussion of libraries and frameworks
309957 by: Adam Richardson
309959 by: Tommy Pham
Re: code quest - ECHO?!?
309960 by: Kirk Bailey
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On 10-12-09 10:41 PM, Daevid Vincent wrote:
-----Original Message-----
If you value CPU time over developer time, by all means avoid ORM
frameworks (and *all* frameworks). The point of a common
framework is to
trade a small bit of performance for a large amount of
developer time. If
you will only use the framework once, the payoff will be
much less. The
goal is to choose frameworks that you can leverage again and again.
I disagree. If you use a framework, then you're stuck with it. Bugs and all
(and trust me there are bugs and limitations you WILL run into). If it's
your code, you can fix it. If it's someone elses' you have to submit a bug
report and HOPE they fix it. If they don't you are now forced with either
patching every new release or working around it.
As for training, you will be able to hire another developer
that knows Doctrine.
Doubtful. It's hard enough to find skilled PHP developers as it is.
Everyone and their mother THINKS they're a LAMP guy. Test them. You quikly
find out that buzzwords on a paper resume are not the same as a real
developer.
It will be impossible to find a developer *anywhere* that
understands your home-grown framework without training.
That's just it. DO NOT make a "framework". Make some helper routines for
common tasks like sql_query(), sql_insert(), sql_update(),
sql_select_box(), etc. and stick to the "basics".
Frameworks are a waste of time and energy -- homegrown or off-the-shelf.
They try to be all things to all people and turn into a "jack of trades,
master of none". They're bloated and cumbersome and force you to wedge
square pegs into round holes all the time.
Nor will you get
help with bugs in your framework or be able to discuss
better ways to use it on forums.
That's what your employees, team-mates, customers, testers, etc. are for...
If you're making "JoeBlowsRinkyDink.com" then go for the framework if you
want to play with it for the massochistic experience and to learn your
lesson the hard way. But don't use it for paying customers and certainly
don't use it in an enterprise level -- it will be the death nail to your
project ultimately.
Use PHP the way God intended it to be used.
Could you cite a reference for where God states his intentions on PHP?
Thanks,
Rob.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.
--- End Message ---
--- Begin Message ---
Robert Cummings wrote:
Use PHP the way God intended it to be used.
Could you cite a reference for where God states his intentions on PHP?
Any PHP developers BLOG ;)
We are all gods ...
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
--- End Message ---
--- Begin Message ---
At 9:53 AM -0500 12/10/10, Robert Cummings wrote:
On 10-12-09 10:41 PM, Daevid Vincent wrote:
Use PHP the way God intended it to be used.
Could you cite a reference for where God states his intentions on PHP?
Thanks,
Rob.
Mark:7:34
And looking up to heaven, he sighed, and saith unto him, e PHP hatha,
that is, Be opened.
If it was to be otherwise, he would have said "Be closed".
Cheers,
tedd
--
-------
http://sperling.com/
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: tedd [mailto:tedd.sperl...@gmail.com]
> Sent: Friday, December 10, 2010 8:20 AM
> To: Robert Cummings; Daevid Vincent
> Cc: php-gene...@lists.php.net
> Subject: Re: [PHP] ORM doctrine
>
> At 9:53 AM -0500 12/10/10, Robert Cummings wrote:
> >On 10-12-09 10:41 PM, Daevid Vincent wrote:
> >>
> >>Use PHP the way God intended it to be used.
> >
> >Could you cite a reference for where God states his intentions on PHP?
> >
> >Thanks,
> >Rob.
>
> Mark:7:34
>
> And looking up to heaven, he sighed, and saith unto him, e PHP hatha, that
> is, Be opened.
>
> If it was to be otherwise, he would have said "Be closed".
>
> Cheers,
>
> tedd
> --
> -------
> http://sperling.com/
>
I should have titled it just 'doctrine' since the list automatically
prepends PHP :D
Regards,
Tommy
--- End Message ---
--- Begin Message ---
On Dec 10, 2010, at 11:20 AM, tedd wrote:
> At 9:53 AM -0500 12/10/10, Robert Cummings wrote:
>> On 10-12-09 10:41 PM, Daevid Vincent wrote:
>>>
>>> Use PHP the way God intended it to be used.
>>
>> Could you cite a reference for where God states his intentions on PHP?
>>
>> Thanks,
>> Rob.
>
> Mark:7:34
>
> And looking up to heaven, he sighed, and saith unto him, e PHP hatha, that
> is, Be opened.
>
> If it was to be otherwise, he would have said "Be closed".
>
> Cheers,
>
> tedd
> --
> -------
> http://sperling.com/
Tedd-
I guess it's time to starting being religious again if they have upgraded the
Bible to suit my interests.
Thanks for the laugh!
Regards,
-Josh
____________________________________
Joshua Kehn | josh.k...@gmail.com
http://joshuakehn.com
--- End Message ---
--- Begin Message ---
On 12/10/10 8:53 AM, Robert Cummings wrote:
Use PHP the way God intended it to be used.
Could you cite a reference for where God states his intentions on PHP?
Thanks,
Rob.
According to Rasmus, it's as a thin integration layer on top of PECL
modules written in C, most of which are just wrappers around Unix C
libraries that existed in the early 90s.
Everything else is an abomination. That means all of your code (for any
definition of "your").
--Larry Garfield
--- End Message ---
--- Begin Message ---
On 10-12-10 11:38 AM, la...@garfieldtech.com wrote:
On 12/10/10 8:53 AM, Robert Cummings wrote:
Use PHP the way God intended it to be used.
Could you cite a reference for where God states his intentions on PHP?
Thanks,
Rob.
According to Rasmus, it's as a thin integration layer on top of PECL
Perhaps that was the intent... but destiny has more plans than that of a
mere mortal... great as he may be.
Cheers,
Rob.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.
--- End Message ---
--- Begin Message ---
On Thu, Dec 9, 2010 at 7:41 PM, Daevid Vincent <dae...@daevid.com> wrote:
> I disagree. If you use a framework, then you're stuck with it. Bugs and all
>
(and trust me there are bugs and limitations you WILL run into).
I have fixed bugs locally in third party libraries; I have submitted them
for patching; I have received fixes from other people for them; and I have
had them accepted. This must be factored in to your choice of tool. Don't go
with the project that hasn't had any commits in over a year. Also, projects
lead by a single person with no other committers bring risk.
> If it's your code, you can fix it.
>
If it's your code, you are the only eyes looking at it and the only one that
can fix it. It's a trade-off.
Doubtful. It's hard enough to find skilled PHP developers as it is.
>
If that's the case, you're already behind the eight ball. Whether you use
someone else's code or your own, they won't be able to learn it. At least
with an outside tool there's a slim chance they've worked with it before.
That's just it. DO NOT make a "framework". Make some helper routines for
> common tasks like sql_query(), sql_insert(), sql_update(),
> sql_select_box(), etc. and stick to the "basics".
>
This discussion started about ORM, and I think we've moved on to third-party
libraries. By using "framework" as you have, you're narrowing the
conversation considerably to a handful of libraries at most (Zend, Cake, any
others for PHP?). By framework I mean a collection of related helper
routines, classes, methods, etc. that make performing a specific access of
coding easier.
[I wrote]
>
> Nor will you get
> > help with bugs in your framework or be able to discuss
> > better ways to use it on forums.
>
> That's what your employees, team-mates, customers, testers, etc. are for...
>
I prefer my network of help to include thousands of coders rather than a
handful.
If you're making "JoeBlowsRinkyDink.com" then go for the framework if you
> want to play with it for the massochistic experience and to learn your
> lesson the hard way. But don't use it for paying customers and certainly
> don't use it in an enterprise level -- it will be the death nail to your
> project ultimately.
>
I've successfully used frameworks for small customers, large customers, in
the enterprise and at startups. I've also written my own libraries to
perform more narrow tasks in the same environments. Use the right tool for
the job; don't be dogmatic in your decisions or you'll end up wasting time
or other resources.
To bring this back around to ORMs specifically, if you are going to build a
lot of database-driven applications and you want to use object-oriented
techniques rather than passing around a bunch of arrays, take some time to
investigate the options. If you find a tool you like, your time investment
to learn it will pay off in spades with each new project. You only need to
learn it once; it will save you time again and again after that.
David
--- End Message ---
--- Begin Message ---
At 7:04 PM +0000 12/8/10, Ashley Sheridan wrote:
I'd also check any errors logs for this site made by Apache, as that
will tell you where PHP is falling over. If you have access to the
whole server run a 'tail -f' command in a terminal and go to your
site again in the browser, that way, you'll see the new error
messages as they come in.
Thanks,
Ash
Ash:
Oddly enough, I just learned of that within this last year or two.
Most of my past host did not have errors logs placed in a convenient
and obvious place for me to notice them.
However, when I started hosting with Daniel Brown (great host BTW) I
noticed errors logs appearing in my on-line working folders. Not
really knowing what they were, I looked and now they became something
I rely upon.
So, if your host provides them, then look for errors within.
Cheers,
tedd
--
-------
http://sperling.com/
--- End Message ---
--- Begin Message ---
On Fri, Dec 10, 2010 at 8:26 AM, Bob McConnell <r...@cbord.com> wrote:
> From: Adam Richardson
>
> > As one point of curiosity, I'm wondering when a function or group of
> > functions is, in your eyes, deemed a library. I tend to use the
> pornography
> > approach to identifying a library ("I know it when I see it"), but I'm
> sure
> > there's a more formal analysis. For some, maybe it's as simple as
> "The
> > developer calls this a library." :)
>
> As soon as you bundle a set of functions into a separate package that
> can be shared between projects, developers or teams, you have a library.
> I believe this is true even if there is only a single function in the
> bundle. Some libraries are quite extensive, and may even include a
> complete framework. But the distinction is the bundling that makes them
> independent of any specific project.
>
>
Well stated, Bob.
--
Nephtali: PHP web framework that functions beautifully
http://nephtaliproject.com
--- End Message ---
--- Begin Message ---
I think I didn't hit reply-all. PICNIC moment :D
> -----Original Message-----
> From: Tommy Pham [mailto:tommy...@gmail.com]
> Sent: Friday, December 10, 2010 11:01 AM
> To: Adam Richardson
> Subject: Re: [PHP] A general discussion of libraries and frameworks
>
> On Fri, Dec 10, 2010 at 9:23 AM, Adam Richardson <simples...@gmail.com>
> wrote:
> >
> >
> > On Fri, Dec 10, 2010 at 7:07 AM, Tommy Pham <tommy...@gmail.com>
> wrote:
> >>
> >> > -----Original Message-----
> >> > From: Adam Richardson [mailto:simples...@gmail.com]
> >> > Sent: Friday, December 10, 2010 12:05 AM
> >
> > ...
> >>
> >> > I use frameworks when there is a particular flow I wish to enforce
> >> > throughout the application. For instance, my web framework
> >> > enforces a general flow during all requests:
> >>
> >> Adam,
> >>
> >> I find that 'enforce' leads to inflexibility eventually.
> >
> > You're absolutely right, choosing to use a framework does mean that
> > you give up some flexibility. The degree of flexibility you loose
> > seems to depend on how many areas of flow the framework tries to
> determine.
> >
> >>
> >> As for framework,
> >> I'm still looking for a good implementation of the presented concept
> >> (MVC, ORM, etc.). Case in point: MVC. You could just add or do some
> >> minor change in either/all the Model, View, or Controller, having
> >> that flexibility to adapt w/o major base code change is very nice.
> >> The problem lies therein of implementing the abstract concept MVC
> >> into concrete, workable (learning, understanding, maintaining, etc.),
> >> reliable, and flexible (modular, 3rd party add-ins, etc.) code while
> >> retaining good performance. IE: Zend Framework. The code base is
> >> somewhat bloated, IMO. But as others have mentioned, it's still
> >> useful due to its modular design as you can choose to use parts of it
> >> within your app and not need to implement the entire framework. I
> >> don't have enough experience with ZF yet to see how expandability it
> >> is in terms of third party add-in/plugin/module. Here's the list of
> >> PHP frameworks [1]. I don't know how current it is. As you can see
> >> from that table, only 2 supports everything that's current under the
> >> sun, including template & event driven.
> >
> > Nice points.
> > In terms of supporting everything, I rarely look to see how many
> > things a framework supports, I look at how well the framework supports
> > the flow-related aspects of my application I really need. I can
> > always use a library to fill in the holes if the framework's core
> > merits (usability, extensibility, etc.)
>
> The main reason why I look at the features of the framework simply that
> should my project is based upon it, even though I don't use all of the
> features, someone later may develop a plug-in to further enhance the
> quality of the project and like to use a feature from that same framework,
> that I didn't use.
>
> >>
> >> Yii isn't very mature from what I've
> >> read so far. PRADO's, although acronym is both catchy and
> >> meaningful, code base is too much ASP.NET like even though it's based
> >> on PHP >.>.
> >> Ironically, both projects are started by the same person.
> >
> > Both are nice frameworks, with Yii being an exceptional point of interest.
> > Given your priorities, I'm curious if you've tried frameworks like
> > Code Igniter or the Fat Free Framework. Both are small enough that
> > they feel quite flexible.
>
> No, I haven't looked at those as I'm looking for something that will give me
> the following, or have the ability to accept the following plug-ins, for my
> project based on a concept I have:
>
> * MVC - excellent to model after the business
> * Multiple DB's - so my project can be used anywhere
> * ORM (optional and if it meets the points mentioned above)
> * DB Objects - allows flexibility within the app and the DB backend
> * Templates - for more flexible UI
> * Caching - the very last thing I'll implement upon/after project maturity.
> (I
> understand all of the benefits and shortcomings. Most of its usage I've seen
> so far is solve a problem that should never happen in the first place.)
> * Validation - what app would be w/o validation these days
> * Ajax - rich UI and performance
> * ACL - I'm not sure that Auth modules mentioned in the table would fully
> provide ACL
> * Event Driven - that saids it all.
> * SOAP
>
> Since some of the frameworks doesn't have most of the above features, I
> didn't look at those. I'll put some time to look into CodeIgniter, Cake, and
> yours later.
>
> > Also, there are frameworks that don't force an MVC-styled routing
> > mechanism on you. My web framework allows you to map dynamic
> > functionality onto existing website (legacy PHP code and all), whilst
> > providing the flow for any new added functionality.
> > Nice commentary, Tommy.
> > Adam
> >
> > --
> > Nephtali: PHP web framework that functions beautifully
> > http://nephtaliproject.com
> >
>
> Thanks. I need MVC simply for the fact that it will reduce my project's code
> base size. As for MVC styled framework, I think PureMVC is good so far
> although it lacks many of the features I'm looking for. It was created
> originally for Flash based but since been ported over to C#, ColdFusion,
> Haxe, Java, JavaScript, Objective C, PHP, Python, and Ruby. It's API based
> and natively supports modules while allowing both sync and async
> execution.
>
> Regards,
> Tommy
--- End Message ---
--- Begin Message ---
Ok, so what is echo, and how is it different from print.
The code in code quest used echo. I have a copy of learning php 5.0 from
O'Reilly, and noplace does it mention echo. Why? What's the difference?
IS there a difference? Is there an advantage to either? Please clarify
for this newbie.
--
end
Very Truly yours,
- Kirk Bailey,
Largo Florida
kniht
+-----+
| BOX |
+-----+
think
--- End Message ---
