php-general Digest 17 Jun 2011 19:20:10 -0000 Issue 7363
Topics (messages 313582 through 313591):
Re: Doctrine madness!
313582 by: æç½|åä¸æ¥
313584 by: admin.buskirkgraphics.com
313590 by: Floyd Resler
what kind of features would you like in php orms?
313583 by: æç½|åä¸æ¥
313587 by: jean-baptiste verrey
313588 by: æç½|åä¸æ¥
313589 by: jean-baptiste verrey
Re: Best way to create an image with flowing text?
313585 by: Richard Quadling
Performance gain when not using prepared statements?
313586 by: Vitalii Demianets
313591 by: Eric Butera
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 ---
2011/6/17 Nathan Nobbe <quickshif...@gmail.com>
> On Thu, Jun 16, 2011 at 3:58 PM, Eric Butera <eric.but...@gmail.com>
> wrote:
>
> > On Thu, Jun 16, 2011 at 5:37 PM, Daevid Vincent <dae...@daevid.com>
> wrote:
> > >> -----Original Message-----
> > >> From: Nathan Nobbe [mailto:quickshif...@gmail.com]
> > >> Sent: Thursday, June 16, 2011 9:51 AM
> > >> To: php-gene...@lists.php.net
> > >> Subject: [PHP] Doctrine madness!
> > >>
> > >> Hi gang,
> > >>
> > >> If anyone out there has some experience w/ Doctrine now would be a
> great
> > >> time to share it!
> > >
> > > Yeah, I've used Doctrine as part of Symfony. Both suck balls and are a
> > perfect example of why you should NEVER use frameworks. Lesson learned
> the
> > hard way. Re-write with your own MySQL wrappers and for the love of God
> and
> > all that is holy do NOT make it an ORM wrapper.
> >
>
> some of the functionality doctrine has is amazing and it is a big time
> saver
> for sure. sf is also one of the smoothest frameworks ive used in php. i
> think this goes to show you that frameworks don't to *everything*
> perfectly,
> nor can they.
>
> what i find more painful is the fact that 130+ ppl on the doctrine irc
> channel can't offer anything but a shoddy workaround that they assume i'm
> too dumb to have already thought of myself. when in reality, it's like
> 'no,
> your crappy library has a bug in it, could you please address that...'
>
> what is even more disheartening is that through php itself, i have no way
> of
> deciphering which variable is holding this memory or any way to go about
> freeing it, even with the magic circular reference handling of 5.3. that
> bodes badly for php, plain and simple.
>
> what it really amounts to is php is good at doing 1 thing and 1 thing only,
> generating web pages. for anything else, including command line scripts
> that run for more than 30 seconds, choose an actual programming language or
> be prepared to deal w/ hacky, disgusting workarounds.
>
it is sad to be acknowledged that php still has no significant progress in
orm libraries.
but i would still be confident in that php is good for web programming and
it does not one thing but many good comparing to the other many languages
such as python, ruby etc.
it is simple to start, easy to control, extensive to integration, mature for
profiling and performance tuning, low cost in learning etc.
although the language its self is not every good in a manner of structured,
object-oriented, etc. i think i see none language in such a manner. and you?
>
> -nathan
>
--- End Message ---
--- Begin Message ---
While I do agree with your discloser of the bloat for all off the shelf
frameworks.
I created my own framework and my development time drop drastically and not
by a few hours, in some cases days.
The complaint of time is always an issue, if you do not scope out a project
properly.
Timelines and IPR's (In Process Reviews) will keep the developers sane, and
the customer happy.
It tells the customer: I have given you expectation timelines on how long it
will take me to get to each point in development.
It also gives you an opportunity to find obstacles in development that can
be discussed or redirected with another option before the project begins.
Any added edge on the timelines, allows for extra creativity and pit falls.
The worst thing you can do? Not take time to understand your development
process and coding practices.
To use someone else's framework is asking for trouble.
Like most who download a framework, install it. They just setup the config
and start programming.
Bad, Bad, BAD!!!!
If you took the time to flow through the framework, you might understand all
the things you never want to happen that can cause serious latency issues.
Then soon learn, you are better off just writing your own or developing a
coding practice that keeps your timelines consistent.
If you are using a database, PLEASE learn what is called Relational
modeling.
The fastest server in the world will not help a poorly designed database,
causing 78% of all latency in projects that are DB driven.
I never claimed to be the expert here, I just know what has made me very
successful.
Richard L. Buskirk
-----Original Message-----
From: Paul M Foster [mailto:pa...@quillandmouse.com]
Sent: Friday, June 17, 2011 1:46 AM
To: php-gene...@lists.php.net
Subject: Re: [PHP] Doctrine madness!
On Thu, Jun 16, 2011 at 08:53:18PM -0400, Eric Butera wrote:
> On Thu, Jun 16, 2011 at 7:32 PM, Daevid Vincent <dae...@daevid.com> wrote:
> >
[snip]
>
> I'm sorry but this is absolute rubbish. I used to write my queries by
> hand, but over time you start to realize that perhaps, maybe writing
> out thousands of identical lines of code over hundreds of projects
> might not be an efficient usage of time. If you have performant
> requirements, that is one thing and can easily be overcome with slight
> deviations on a case by case basis. Most of the time, contrary to
> your position, things just need to work and be completed quickly.
> What is the more common question from clients: why is this so slow,
> or, client asks why is this not finished yet?
I generally side with Daevid on this, though my position isn't as
extreme. However, I have to take exception to the "either/or" question
from clients. As far as I'm concerned, clients need to learn that coding
takes as long as it takes. I'd much rather spend the extra time and
never have the customer ask why the code is so slow. The theoretical
alternative, having the customer satisfied with the delivery time, but
complain about latency, isn't what I'd consider acceptable.
Looking at some of the code that comprises most ORM and other frameworks
(but particularly ORM frameworks) the bloat is amazing.
Paul
--
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
On Jun 17, 2011, at 3:05 AM, <ad...@buskirkgraphics.com>
<ad...@buskirkgraphics.com> wrote:
> While I do agree with your discloser of the bloat for all off the shelf
> frameworks.
>
> I created my own framework and my development time drop drastically and not
> by a few hours, in some cases days.
>
> The complaint of time is always an issue, if you do not scope out a project
> properly.
> Timelines and IPR's (In Process Reviews) will keep the developers sane, and
> the customer happy.
>
> It tells the customer: I have given you expectation timelines on how long it
> will take me to get to each point in development.
> It also gives you an opportunity to find obstacles in development that can
> be discussed or redirected with another option before the project begins.
> Any added edge on the timelines, allows for extra creativity and pit falls.
>
> The worst thing you can do? Not take time to understand your development
> process and coding practices.
>
> To use someone else's framework is asking for trouble.
> Like most who download a framework, install it. They just setup the config
> and start programming.
>
> Bad, Bad, BAD!!!!
> If you took the time to flow through the framework, you might understand all
> the things you never want to happen that can cause serious latency issues.
> Then soon learn, you are better off just writing your own or developing a
> coding practice that keeps your timelines consistent.
>
> If you are using a database, PLEASE learn what is called Relational
> modeling.
> The fastest server in the world will not help a poorly designed database,
> causing 78% of all latency in projects that are DB driven.
>
>
> I never claimed to be the expert here, I just know what has made me very
> successful.
>
> Richard L. Buskirk
I've taken pretty much the same approach. After trying several different
frameworks, I found it frustrating that, other than the blog tutorial that each
one has, I couldn't get any of them to work the way I wanted to. Granted, this
was probably due to me wanting to dive right in and start developing larger
sites as opposed to starting simple to learn the frameworks. The most
frustrating thing for me was when something went wrong and trying to figure out
what caused the problem. So, understanding MVC, I built my own framework and,
just like you, have cut my development time down considerably! With a simple
script, I can generate the files I need and I have a nice looking page in
seconds. Of course, it doesn't do anything at that point but it has all my
JavaScript and CSS files loaded, any page headers (such as images) displayed,
and a menu bar (if the site requires it).
I have really enjoyed writing my own framework and making it better throughout
the years. It has saved me considerable time!
Take care,
Floyd
--- End Message ---
--- Begin Message ---
and how to design such an orm in current state of php language?
--- End Message ---
--- Begin Message ---
- defining the mapping schema in an alternate method than using meta data (I
HATE them, I would prefer an XML file with a DTD so you could use
autocompletion with IDE like NetBeans)
- clear keywords in the schema
- OQL can do UPDATEs
- one and only one configuration file with everything in it (and with why
not the schema)
- to not forget to KEEP IT SIMPLE, specialised ORM that does everything
already exists so there's no point in writing one!
that's it for me (at least at the moment)
Of course I would suggest to use PHP 5.3 specially for late static binding
(and for people that love namespaces)
On 17 June 2011 07:42, 李白|字一日 <calid...@gmail.com> wrote:
> and how to design such an orm in current state of php language?
>
--- End Message ---
--- Begin Message ---
thanks, how about the abstraction of different databases?
it seems PDO is still lack of functions of importance.
I'm currently trying to design a automated model like django or
activeRecord.
it should be quiet simple and automated,
i have managed to possibly create the whole database only once.
but the abstraction of the database and subsequent manipulation seem far
more complicated than the previous part
i'm currently only support mysql and only support whole query at once.
2011/6/17 jean-baptiste verrey <jeanbaptiste.ver...@gmail.com>
> - defining the mapping schema in an alternate method than using meta data
> (I HATE them, I would prefer an XML file with a DTD so you could use
> autocompletion with IDE like NetBeans)
java's hibernate instead of python's exlir or ruby 's rail style ? mean no
ActiveRecord?
> - clear keywords in the schema
>
> - OQL can do UPDATEs
>
- one and only one configuration file with everything in it (and with why
> not the schema)
>
- to not forget to KEEP IT SIMPLE, specialised ORM that does everything
> already exists so there's no point in writing one!
>
> that's it for me (at least at the moment)
>
> Of course I would suggest to use PHP 5.3 specially for late static binding
> (and for people that love namespaces)
>
>
>
> On 17 June 2011 07:42, 李白|字一日 <calid...@gmail.com> wrote:
>
>> and how to design such an orm in current state of php language?
>>
>
>
--- End Message ---
--- Begin Message ---
You could simply use like doctrine DBAL or an already existing one made
specially for ORM, or you can design one and at the moment make it to use
only MySQL
PDO is actually good enough to do that, I know that the only thing I had to
do in my ORM was to write a special class to translate some queries for
MySQL (to be able to use LIMIT for objects instead of rows).
On 17 June 2011 12:06, 李白|字一日 <calid...@gmail.com> wrote:
> thanks, how about the abstraction of different databases?
> it seems PDO is still lack of functions of importance.
>
> I'm currently trying to design a automated model like django or
> activeRecord.
> it should be quiet simple and automated,
> i have managed to possibly create the whole database only once.
> but the abstraction of the database and subsequent manipulation seem far
> more complicated than the previous part
>
> i'm currently only support mysql and only support whole query at once.
>
> 2011/6/17 jean-baptiste verrey <jeanbaptiste.ver...@gmail.com>
>
>> - defining the mapping schema in an alternate method than using meta data
>> (I HATE them, I would prefer an XML file with a DTD so you could use
>> autocompletion with IDE like NetBeans)
>
>
> java's hibernate instead of python's exlir or ruby 's rail style ? mean no
> ActiveRecord?
>
>
>> - clear keywords in the schema
>>
>
>
>> - OQL can do UPDATEs
>>
>
> - one and only one configuration file with everything in it (and with why
>> not the schema)
>>
>
> - to not forget to KEEP IT SIMPLE, specialised ORM that does everything
>> already exists so there's no point in writing one!
>>
>> that's it for me (at least at the moment)
>>
>> Of course I would suggest to use PHP 5.3 specially for late static binding
>> (and for people that love namespaces)
>>
>
>
>
>>
>
>>
>> On 17 June 2011 07:42, 李白|字一日 <calid...@gmail.com> wrote:
>>
>>> and how to design such an orm in current state of php language?
>>>
>>
>>
>
--- End Message ---
--- Begin Message ---
On 16 June 2011 23:59, Brian Dunning <br...@briandunning.com> wrote:
> Hey all -
>
> I need to create PNG images with transparent backgrounds that contain text.
> The text will come from four fields in a database, and needs to be centered,
> and text wrapped. The fields are going to be of varying lengths, so each
> block of text (which will be shown in a different font size) will flow onto
> an unknown number of lines, and I want to start the next line right below,
> wherever it is.
>
> Unfortunately I have come up against some restrictions.
> - I will not be able to use ImageMagick.
> - I have Ghostscript, but only version 7.07.
> - The server is Red Hat 4.x with PHP 5.2 and installing new software
> is unlikely.
>
> Can anyone suggest a tool to make this easiest?
> :-(
>
> - Brian
Do you have the image extension loaded?
A LONG time ago (nearly 7 years ago - just when I first started using
PHP - so please forgive the code), I built a script to take words and
scale them to fill a box.
The technique of getting the size of the text could still be useful here.
It was in response to a question on Experts Exchange
(http://www.experts-exchange.com/Web_Development/Web_Languages-Standards/PHP/Q_21113446.html#a11972605)
The code is awful by my current standards. But it worked. So there
must be something in that.
I'll send you the code directly as, frankly, it is embarrassing to see today.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--- End Message ---
--- Begin Message ---
On Friday 17 June 2011 04:50:00 Daevid Vincent wrote:
> > I've seen too many people over the years try and rally against common
> > sense practices like using prepared statements for perhaps a marginal
> > gain of performance on one page while their load averages are 0,0,0.
>
> Agreed. The ONLY time prepared statements are useful, is in a loop where
> you're changing a few variables but within the same SQL statement. That is
> a rare case for most people.
>
Not ONLY. I love prepared statements because with them I can store arbitrary
strings in DB without need to worry about fancy escaping and SQL injection.
And do it in DB-independent way.
Think about all that extra escaping and performance gain of not using prepared
statement will shrink a lot ) Don't have actual numbers though.
--
Vitalii
--- End Message ---
--- Begin Message ---
On Fri, Jun 17, 2011 at 4:55 AM, Vitalii Demianets
<vi...@nppfactor.kiev.ua> wrote:
> On Friday 17 June 2011 04:50:00 Daevid Vincent wrote:
>> > I've seen too many people over the years try and rally against common
>> > sense practices like using prepared statements for perhaps a marginal
>> > gain of performance on one page while their load averages are 0,0,0.
>>
>> Agreed. The ONLY time prepared statements are useful, is in a loop where
>> you're changing a few variables but within the same SQL statement. That is
>> a rare case for most people.
>>
>
> Not ONLY. I love prepared statements because with them I can store arbitrary
> strings in DB without need to worry about fancy escaping and SQL injection.
> And do it in DB-independent way.
> Think about all that extra escaping and performance gain of not using prepared
> statement will shrink a lot ) Don't have actual numbers though.
>
> --
> Vitalii
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
You can implement caching at so many levels of the app that using a
prepared statement should be at the lower spectrum of your worries.
It is too easy to forget calling escape whether it be for a DB or
output to the browser as proven by all the various bug trackers and
hacked websites across the net.
Just to drive this point home, if you do a quick search on Secunia for
'SQL Injection' [1] you get 4,158 advisories. Worth the risk?
http://secunia.com/advisories/search/?search=sql+injection
--- End Message ---
